qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          數據庫范式設計

           在軟件開發過程中,數據庫的設計是非常重要的??梢哉f,良好的數據庫設計,是對用戶需求的理解的精準定位。它不僅能夠使得軟件開發起來非常便捷,而且還能夠使軟件系統高效運行,同時,為日后的維護或者更換數據庫提供便利。

            在最近開發系統的過程中,感覺收獲最大的也是關于數據庫的操作。最初開發機房收費系統的時候,由于沒有經驗,而且懂得的知識也非常少,數據庫的設計根本談不上,就是感覺到數據庫中缺少某些字段的時候,直接在數據庫表中去修改字段。這樣就為自己徒增了很多工作量,相關的代碼需要一處一處去修改。

            開發.NET版機房收費系統的數據庫設計明顯好多了,由于充分了解了需求,數據庫設計當然比上一次好上很多。不過回頭去看,數據庫的設計還是存在很多的缺陷。表中仍然存在著大量的冗余字段,增刪改后也會出現發生一些異常。

            在牛腩新聞發布系統中,由于系統非常小,對于數據庫的操作也就那兩下子,復雜也到不了哪里去。不過盡管如此,感覺牛老師的數據庫設計還是非常規范的。類別、評論、新聞分別放在三個表中,完全沒有冗余數據。

            廢話太多了,開始步入正題了。良好的設計能夠使程序員的工作事半功倍。

            首先,先來看官方解釋:

            第一范式是指數據庫表的每一列都是不可分割的基本數據項,同一列中不能有多個值,即是實體的某個屬性不能有多個值或者不能有重復的屬性。

            第二范式是指數據庫表中不存在非關鍵字段對任一候選關鍵字段的部分函數依賴。

            第三范式數據庫表中不存在非關鍵字段對任一候選關鍵字段的傳遞函數依賴。

            簡單來說,第一范式是講數據庫表中數據的原子性,數據不可再分,只要是關系型數據庫都必須首先滿足第一范式??聪聢D例子:圖1中三個字段不可再分,故滿足第一范式;圖2將專業、年級、班級三個字段放在一個字段里面,就不符合第一范式了。

                    

            下面再來看機房收費系統中的一個表設計——學生基本數據表。

          圖A

            圖A中由于每一個字段都不可再分,故它是滿足第一范式的。然而這樣的設計就會產生大量的冗余字段。如果一個學生注冊兩個卡,那么該學生的信息就需要重復兩次。

            第二范式就解決了上述問題。它強調其屬性必須完全依賴主鍵,實體的屬性不能僅僅依賴主關鍵字的一部分屬性。如果存在部分依賴關系,那么這個屬性和主關鍵字相應部分應該分離出來形成一個新的實體,實體與原始體之間是一對多的關系。

            像上面例子中,很顯然主鍵是卡號和學號聯合做主鍵,其中姓名、性別、系別、專業、年級、班級都只與學號有關,只依賴學號,而不依賴卡號,這樣就不符合第二范式了。

            我們的根據第二范式的要求,將其與學生相關的信息分離出來,修改后,我們可得一下兩個表:

          圖B

            然而,僅僅滿足第二范式的數據庫是遠遠不夠的,滿足第二范式,仍然可能會出現傳遞依賴。圖B學生表中系別與專業存在傳遞關系。假如小紅和小明的系別都是數信學院,專業都是數學專業,那么這樣數據庫中系別就重復了兩次,增加了冗余字段。

           第三范式保證了同一類事物分在一個表中,消除了傳遞依賴的現象。我們再根據第三范式的設計要求,將其學生表在進行分離,得到下面的表:

          圖C

            下面給出圖C的數據庫關系圖:

            好的數據庫設計,是軟件開發中非常重要的一步。三范式設計只是一個標準,對于基本表的設計,建議大家盡量按照三范式的要求進行設計;而對于臨時表的設計,我們可以適量的增加一些冗余字段,畢竟單一表的查詢檢索速度比較快,提高了系統性能。

          posted @ 2012-04-26 09:34 順其自然EVO 閱讀(217) | 評論 (0)編輯 收藏

          以測試為核心的軟件開發過程

           摘要:軟件項目規模越來越大,開發團隊人員越來越多,人員增加帶來管理成本上升,于是引入ISO9000、CMM,但最后發現它們實施難度相當大。于是我們介紹一套行之有效的測試控制方法,它能夠有效對軟件項目開發進行控制。

            關鍵詞:軟件測試;軟件開發;軟件項目管理

            1、引言

            TC(測試控制方法)是指以測試為核心控制軟件項目開發過程的方法,它包括完整的規范TC 系統及其相關管理理論TC 理論。主要完成軟件開發中開發流程的管控、軟件測試、開發績效評價、持續改進管控質量等功能。

            ● 我們先來看一看軟件項目開發中經常遇到的問題。

            ● 各模塊一拖再拖,整個項目無休止延期,開發進度無法得到控制;

            ● 改正了舊問題,又冒出更多新問題,問題層出不窮;

            ● 模塊難度、工期質量考核無法量化,更無法與個人收入掛鉤;

            ● 技術攻關、需求、分析與設計階段任務難以進行驗收;

            ● 項目負責人需要時刻關注各開發人員的開發過程,沒有時間進行項目整體規劃;

            ● 項目負責人經常感到失控,開發人員開發出的結果往往與預期效果差異很大;

            ● 項目負責人在模塊嚴重拖期時,不知是應該換人重做,還是再讓其開發幾天;

            ● 項目經理對各開發團隊的開發能力沒有客觀的認識;

            ● 項目經理對各項目的進度情況不能有效把握,經常被告之以“馬上就完了”這樣含糊的承諾;

            ● 項目經理對自主開發的產品沒有量化的質量評價;

            ● 所有這些問題都在TC 系統中迎刃而解。

            2、TC 系統依賴全新的管理思路

            ● 做出好軟件

            好的軟件是做出來的,不是改出來的。軟件必須依靠具有一定水平的開發人員集中精力開發,不可能靠反復的修改來完成。軟件修改次數越多,出錯的可能性就越大。

            ● 測試的任務

            測試的主要任務是控制開發人員隨意提交低質量的程序。例如:我們在測試中有個定義叫返回,意思是,當開發人員提交了問題過多的程序后,測試人員可以不用告知程序中的問題,直接返回程序要求開發人員重新修改。這樣既控制了被提交程序的質量,也使測試人員把工作重點從尋找簡單的低級錯誤,轉移到尋找程序中復雜的邏輯錯誤。堅決反對“測試人員是幫助程序人員發現問題的”說法,而強調測試人員是站在一個更高的管理控制層面上。

            ● 績效考核

             項目開發中的工期與質量采用分值進行量化績效考核,不單注重質量或進度,將二者統一起來??冃侵改橙嗽谕瓿梢粋€工單時,質量和工期的綜合評價。一個理 想程序員完成工單的績效為1,比理想程序員完成效果好績效大于1,完成效果差績效小于1,一般程序員的績效在0.7 左右。

            采用量化績效可以對項目人員績效進行考核排隊,并與個人收入掛鉤。采用量化績效還能將從事不同類型工作的項目人員進行排隊,如:對開發人員和售后服務人員績效進行排隊。

            ● 弱化人際關系

            項目管控過程中對事不對人,由軟件系統確定處理流程,郵件方式傳遞信息,避免人情關、面子關,減少在人為交流中的沖突與不確定性。

            ● 全面管控

            借鑒ISO9000 質量管理體系的思想,遵循“怎么想就怎么寫,怎么寫就怎么做,怎么做就怎么記”。所有工作做到統一安排、有據可依、有史可查。

            3、實現流程

            TC 可以在整個項目的開發過程中進行管控。需求分析,技術攻關,分析與設計,構造實現,測試部署階段,甚至在售后服務階段都可以使用TC 系統進行控制。

            所有工作都以工單的形式派發并跟蹤驗收。各工單按以下流程進行控制:

          圖一

            開發團隊接到新項目,明確工作內容后,就可以使用TC 系統控制整個項目直至結束。制訂工作計劃;派發各階段的工單,驗收工單,封版;如此循環,直至所有工單都封版,表明項目開發完成。

           摘要:軟件項目規模越來越大,開發團隊人員越來越多,人員增加帶來管理成本上升,于是引入ISO9000、CMM,但最后發現它們實施難度相當大。于是我們介紹一套行之有效的測試控制方法,它能夠有效對軟件項目開發進行控制。

            關鍵詞:軟件測試;軟件開發;軟件項目管理

            1、引言

            TC(測試控制方法)是指以測試為核心控制軟件項目開發過程的方法,它包括完整的規范TC 系統及其相關管理理論TC 理論。主要完成軟件開發中開發流程的管控、軟件測試、開發績效評價、持續改進管控質量等功能。

            ● 我們先來看一看軟件項目開發中經常遇到的問題。

            ● 各模塊一拖再拖,整個項目無休止延期,開發進度無法得到控制;

            ● 改正了舊問題,又冒出更多新問題,問題層出不窮;

            ● 模塊難度、工期質量考核無法量化,更無法與個人收入掛鉤;

            ● 技術攻關、需求、分析與設計階段任務難以進行驗收;

            ● 項目負責人需要時刻關注各開發人員的開發過程,沒有時間進行項目整體規劃;

            ● 項目負責人經常感到失控,開發人員開發出的結果往往與預期效果差異很大;

            ● 項目負責人在模塊嚴重拖期時,不知是應該換人重做,還是再讓其開發幾天;

            ● 項目經理對各開發團隊的開發能力沒有客觀的認識;

            ● 項目經理對各項目的進度情況不能有效把握,經常被告之以“馬上就完了”這樣含糊的承諾;

            ● 項目經理對自主開發的產品沒有量化的質量評價;

            ● 所有這些問題都在TC 系統中迎刃而解。

            2、TC 系統依賴全新的管理思路

            ● 做出好軟件

            好的軟件是做出來的,不是改出來的。軟件必須依靠具有一定水平的開發人員集中精力開發,不可能靠反復的修改來完成。軟件修改次數越多,出錯的可能性就越大。

            ● 測試的任務

            測試的主要任務是控制開發人員隨意提交低質量的程序。例如:我們在測試中有個定義叫返回,意思是,當開發人員提交了問題過多的程序后,測試人員可以不用告知程序中的問題,直接返回程序要求開發人員重新修改。這樣既控制了被提交程序的質量,也使測試人員把工作重點從尋找簡單的低級錯誤,轉移到尋找程序中復雜的邏輯錯誤。堅決反對“測試人員是幫助程序人員發現問題的”說法,而強調測試人員是站在一個更高的管理控制層面上。

            ● 績效考核

             項目開發中的工期與質量采用分值進行量化績效考核,不單注重質量或進度,將二者統一起來。績效是指某人在完成一個工單時,質量和工期的綜合評價。一個理 想程序員完成工單的績效為1,比理想程序員完成效果好績效大于1,完成效果差績效小于1,一般程序員的績效在0.7 左右。

            采用量化績效可以對項目人員績效進行考核排隊,并與個人收入掛鉤。采用量化績效還能將從事不同類型工作的項目人員進行排隊,如:對開發人員和售后服務人員績效進行排隊。

            ● 弱化人際關系

            項目管控過程中對事不對人,由軟件系統確定處理流程,郵件方式傳遞信息,避免人情關、面子關,減少在人為交流中的沖突與不確定性。

            ● 全面管控

            借鑒ISO9000 質量管理體系的思想,遵循“怎么想就怎么寫,怎么寫就怎么做,怎么做就怎么記”。所有工作做到統一安排、有據可依、有史可查。

            3、實現流程

            TC 可以在整個項目的開發過程中進行管控。需求分析,技術攻關,分析與設計,構造實現,測試部署階段,甚至在售后服務階段都可以使用TC 系統進行控制。

            所有工作都以工單的形式派發并跟蹤驗收。各工單按以下流程進行控制:

          圖一

            開發團隊接到新項目,明確工作內容后,就可以使用TC 系統控制整個項目直至結束。制訂工作計劃;派發各階段的工單,驗收工單,封版;如此循環,直至所有工單都封版,表明項目開發完成。

          ● 項目績效正態分布曲線

          圖六

            該曲線Y 軸為工單數目,X 軸為工單績效。整個曲線描述用戶培訓管理系統在開發中各級績效出現次數對比,其中績效為0.2 以下和1.2 以上的很少,績效為0.7 的工單最多,因此可以說明用戶培訓管理系統的開發績效在0.7 左右浮動,平均開發績效接近0.7。

            ● 公司績效正態分布曲線

          圖七

            該曲線描述整個公司在項目開發中各級績效出現次數對比,其中績效為0.2 以下和1.2 以上的很少,績效為0.7 的工單最多,因此可以說明公司的開發績效在0.7 左右浮動,平均開發績效接近0.7。

            若單從平均值來看,圖六和圖七表現的開發能力是相當的,其實不盡然,圖七的正態分布趨勢要比圖六更向0.7 緊縮,從圖上看圖七要瘦于圖六,說明圖七的開發能力更趨于穩定,而圖六的開發能力更難以預料。因此由以上分析得知用戶培訓管理系統開發團隊的平均質量與公 司整體開發質量相當,但遠不如公司整體開發能力穩定。

            5、適用對象

            TC 適合大多數軟件開發團隊。由于她的特點是以測試為核心控制軟件開發過程,因此她更適合于軟件測試人員配備不是非常充裕的團隊,由有限的軟件測試人員就可以擔當起測試與控制的任務。

            對于開發一般企業級應用軟件的開發團隊來說,軟件開發中一般低級錯誤是最多的,通過TC 系統能使一般低級錯誤得到控制,測試人員集中精力于業務邏輯關系測試。一般企業級應用軟件的開發團隊選擇TC 系統將會比選擇任何一家測試或項目管理軟件更實用。

            對于開發控制系統或算法集中的平臺類軟件的開發團隊來說,雖然一般的低級錯誤可能較少,但TC 系統能將任務分配、任務的追蹤、工期質量統計、測試記錄的整理與歸納等工作自動完成,自然可以大大減少測試人員的事務性工作,幫助測試人員關注核心的算法與邏輯關系測試。

            6、結束語

            TC 能有效對軟件項目進行控制, 記錄各階段工作詳細內容,并能夠對原始數據進行挖掘整理,為各類項目人員提供全面多方位的信息表現形式,協助公司和個人客觀認識自身的開發能力,尋找影響開發能力的主要因素,為持續改進提供幫助。

          posted @ 2012-04-26 09:32 順其自然EVO 閱讀(209) | 評論 (0)編輯 收藏

          軟件項目“免坑”指南

           “誰也無法改變現狀,唯有無數程序員血灑大地,才能使項目重建天日。”這一點也不夸張,軟件項目做爛了就是個坑,參與者也不過是填坑的。就像是在魔獸世界戰場遇到國家隊一樣,你贏也贏不了,出也出不去。

            一、坑有多深?

            當我們進入一個項目時,通過不斷觀察我們可以發現我們的項目到底是不是一個坑。造坑的項目,往往具有某些“臭味”,以下是我的一些認識,這些“臭味”即是項目健康狀態不佳的明顯標志:

            ● 編碼規范形同廢紙,代碼質量低下。每個項目都有編碼規范,但真正嚴格實施卻是另一回事。太多的項目把編碼規范作為形式的存在,沒人在乎讓開發人員寫出“人能讀懂的程序”,注釋和命名也成了開發人員的隨心所欲。project上永遠只有開發任務,而幾乎找不到單元測試的時間和代碼審查的時間。在高壓進度之下的項目,顯得如此山寨。當我們還在抱怨自己工資低的時候,就先看看我們的程序還能稱作OOP嗎。

            ● 缺乏文檔或文檔質量低下。前 期文檔很重要,不論是框架的API使用手冊,還是需求或設計文檔,以及各種既定流程的規范,不同種類的模板及核對表,等等這些文檔,對于項目來說都是非常 重要的資源。而往往有些項目,這類文檔就是交由非軟件行業的人員來編寫,或者前期根本不打算在文檔上浪費時間。這就導致了,缺少相關文檔或文檔質量低下, 在軟件構建過程中,開發者和團隊,不得不為這種“表面工程”的產物而糾結。甚至會退回到前期準備工作,完成所需的文檔。有些文檔可以在后期補,但有些必須在前期進行準備,以保住團隊降低風險,減少缺陷引人的幾率并提高編碼質量,如果前期這類文檔沒有做好,那么就會像考前不復習一樣,自食惡果。

            ● 無盡的需求變更,永遠追不上的進度。這 是最常見也是最可怕的,因為無論怎樣,我們都無法完成它??蛻艨赡苷J為改個程序,就像改個Excel一樣簡單省事,甚至會使用可動用的一切權利和資源來推 行變更。好吧,我承認這樣的客戶我遇到過很多。當我向客戶解釋過變更的代價并提供備選方案后,也就只能等待客戶的選擇了,這多少有些運數的成分,但也是無 奈之舉。

            ● 僅僅靠加班應對進度落后。進度落后并不可怕,可怕的是僅靠加班來追趕進度。這是問題的 關鍵,長時間的趕工仍然無法趕上進度,這只意味著項目有某種更深層次的問題,已經不是單開趕工可以解決的了。留意那些長時間加班的項目,他們往往在管理上 存在很大問題,發現這些問題,在你成為PM時,不要犯類似錯誤。

            ● 溝通無門。如果你在一個“叫天 天不應,叫地地不靈”的項目里,那你最好省心吧。項目中溝通很重要,但總有些項目,領導的工作太忙,人就是找不到,發出去的郵件就是沒人回,遇到問題就是 自己扛。在這樣的項目里也有一些好處,比如鍛煉自己的自學能力,以及磨練意志與根性。不過這些,也都是我的自嘲。低效的溝通將導致不必要的返工,這才是我 所痛恨之處。我最為惱火的一段經歷是,甲方要進行變更,開了一周的會沒人通知我,我的小組在這一周里完成了原計劃的數個需求并進入到測試階段, 但這些需求均被砍掉 。本來只有甲方告知是可以調整進度開發其它模塊的,但最終演變為資源的浪費??梢?,溝通是多么的重要。

            ● 沒人關心質量。因 為軟件構建屬于專業領域,客戶并不具備相應領域的知識,由于這種信息不對稱,助長了軟件的質量低下。我們開發的軟件可以是“低等級高質量”的,但不能夠是 “高等級低質量”的。但是,太多的項目不在注重編碼質量,這與軟件構建的復雜度有關,也與整個行業的風氣有關。但不管何種原因,提高代碼質量仍然應該作為 團隊的努力方向。團隊應該獎勵那些,編寫高質量代碼的程序員。如果你的團隊獎勵的是那些,“BUG殺手”(每天修改上百個BUG),而冷落那些缺陷檢出數 量很低的程序員,那么,你的PM是個不懂技術的,至少我本人認為,任何有技術背景的PM都應該獎勵那些正在保持職業操守,認真對待需求,保證代碼質量的程 序員。他們為項目付出了更多,更多的異常處理, 更多的測試調試,更多的檢查,更多的重構,雖然他們的進度并不快,但他們引人的缺陷數量很少。每個做過開發的人都會在質量和進度上做出取舍,而我敬佩那些 選擇質量程序員,因為他們才是真正拿開發當事業的人。在此,向所有努力提高代碼質量的程序員致敬!

            ● 沒人為缺陷買單,沒人為自己的成果負責。需 求產出了低質量的文檔,設計沒有進行充分的迭代,開發可以怎么簡單怎么寫,測試可以隨意測測,沒人為自己的成果中的缺陷買單,除了項目經理,他為項目承擔 唯一責任。當項目組所有人員都在混時,就是在給自己挖坑。這種缺陷的堆積,會像放射性元素在食物鏈中的堆積一樣,早晚項目會因此而崩潰。

            ● 過高的離職率。這 個是最明顯的“臭味”,這說明我們的同行已經在這里無法忍受了。它所帶來的惡略影響不光體現在可用資源的減少,還體現在對成員士氣的極大影響。如果不及時 改善,這將是一個非常惡性的循環,當往一個進度落后的項目中添加資源只會使進度進一步落后,而非正離職導致必須補充新的資源,資源從入職到培訓都會對對團 隊產生震蕩,并降低現行團隊的生產力。一個頻繁處于形成階段的團隊,很難要求其有什么凝聚力,團隊問題將會凸顯,尤其是在溝通上,在項目忙的時候很少能照 顧到新人?;ㄙM在對新人進行培訓,和與其溝通上的時間,很可能得不償失。

            ● 團隊中的不良情緒。不 同團隊開始扎堆并相互敵視,例如開發組認為設計組是一幫搞業務的白癡,根本不懂編程;測試組認為開發組的人就是垃圾,BUG提交了多少便還是無法關 閉;PM開始抱怨,自己的成員不配合;成員開始抱怨,PM是個純管理沒資格指揮內行做事。等等,諸如此類的怨念會在團隊中積累,并以某個導火索為契機爆 發。面對現實吧,至少,我遠沒有自己想象的那樣高尚。我承認我曾經會和別的程序員說:“你看XX他們寫的代碼...什么呀...”,這樣的話。在過去我也 吐槽過別人代碼,這種做法是錯誤的,我為此表示歉意?,F在,如果有必要,我會說代碼有缺陷,但絕不會說他的代碼不好。我希望,我們能彼此尊重。對于技術人 來說,不尊重他的成果就是不尊重他的人,所以我還是建議PM在管理工作中,多用“缺陷”,少用“不行”、“不對”。但是,項目中也總是有些人,靠鄙視別人 的成果來彰顯自己的實力。這些人,有,但很少。至少我遇到的很少,遇到過幾個,讓他們的話語成為你學習的動力吧。我曾經被人諷刺UI做的太丑,之后我學會了SL和FLEX;被人鄙視基礎太差,之后開始閱讀《CLR Via C#》;我朋友被人嘲笑過數據庫設計,現在人家也開始買書深造。團隊中就是這樣,我們無法管住別人的嘴,但我們可以管住自己的。少說多聽,一鳴驚人,乃上上之策。不要受情緒的影響,保持一個平靜的心。

            ● 沒有項目或階段的后評價。不 對項目的階段進行后評價,也意味著沒人在乎你到底干了些什么,所有人都只是進度是否完成,而沒有對完成的好壞進行評價。這也意味了,僅靠做好你的工作,你 是無法得到領導的重視的。最終只有那些加班時間最長的程序員被領導認可。而能力強,口碑好的成員也只能在團隊和客戶中間留下傳說。

            二、誰在造坑?

            軟件項目涉眾眾多,造坑的多為項目實施團隊內部,而究其原因也是多方面的,但是始終離不了項目的四個維度——時間、范圍、成本、質量。很多時候 客戶并不具備軟件項目的實施經驗,而實施團隊為了迎合客戶意愿,也會多多少少的在這四了維度上做文章。資源、時間不足,輕質量重功能,往往成為造坑的契 機。所以,不用懷疑,造坑的往往是我們自己。很難理解,真正挖出大坑的人,最后也是填坑的人。一個人很容易被外部事務所左右,就如“同假的多了,真的到成 假的了一樣”,多數人不愿意在一個新環境中表現得特立獨行。但也有老的程序員對我說過:“當別人做錯了,你就不要跟著去做!”所以,我認為工作就是工作, 不需要我們在其中融合多少興趣,也不要求我們有過多的付出,但對于工作的成果則要求我們認真的對待。俗話說:“拿多少錢,辦多少事!”如果多少有些團隊意 識,能夠對自己的工作負責,那至少在意識上,我們能給自己少造些坑。

            三、如何免坑?

           ?。ㄒ唬┣宄^

            以下觀點,僅是我對軟件項目中一些錯誤認識的歸納:

            ● 寫出能用的程序就行啦!我們應該首先清楚我們做的是什么,一個成熟的團隊產出的可交付成果應該包括軟件 編程產品,相關文檔,項目實施過程中的經驗教訓已經其它一些非形式的成果(培訓)。這里,我們必須清楚的認識到,我們所開發是是編程產品,而不是我們個人 的技術實踐或大學的畢設。對于編程產品,我們必須認識到,其是產品級別的,必須保證質量,必須提高用戶體驗,必須考慮系統的諸多特性或維度。這一過程遠比 我們自己寫個程序要復雜的多。設計需要不斷地進行迭代;開發人員需要遵守嚴苛的規范,編寫大量的注釋和大量的異常處理;測試人員需要不斷地進行各種重復測 試,但是正是這種全局的規范,全體團隊的不懈努力,才保證了我們的編程產物可以稱之為產品。所以,一定要明確,我們要完成的是一個產品,而不是一個畢業設 計,它不是一個人的技術實踐,而是整個團隊傾注精力去完成的最佳成果。我們可以輕松的實現客戶的某些需求,但需求背后的某些東西,需要我們認真對待,比如 安全性和性能等。實現功能的程序誰都會寫,而寫出高質量的程序的才是真正的藝術。

            ● 盡快開始編碼吧!軟件構件是一個精心設計的過程,其前期準備十分重要。在后期修復缺陷的成本要遠遠高于前期。因此,在項目執行前,前期的規化十分必要。在前期每發現一個缺陷,都會為后期節省大量的成本。

            ● 需求怎么變了!沒有不變的需求。

            ● 進度落后了就招人唄!這是種典型的錯誤認識,《人月神話》中已經說明的很清楚了——往一個進度落后的項 目中注入資源,只會使進度進一步落后。雖然,這本著作成為PM必讀之作,其思想也被業界所廣泛認可,但是,還是會有很多管理者單純的認為,通過注入資源能 解決問題。對于這些人,只能讓實踐來檢驗真理了。

            ● 軟件質量保證是測試的工作!這是一種逃避責任的說辭。如果把代碼質量比喻為減肥,那么測試無疑是一個磅秤,減肥工作還是要有開發人員來完成。所以,不要將代碼質量都寄希望于測試工作上。即使是大規模的用戶測試,其錯誤檢出率也不足五成。而真正挑起代碼質量重擔的是代碼審查。

            ● 程序員你8小時就寫了這么點代碼?讓開發人員將全部時間都花在編碼上是不可能的。開發人員需要時間預讀 文檔,需要與相關干系人進行溝通,需要花時間來搜索資源。此外,可能還需要編寫文檔,參加會議,培訓以及處理個人事務等等。這些時間都會無情的奪走編碼的 時間。程序員大約有近似20%的時間甚至更多會用在與編碼無關的事情上(不算上班或聊QQ),所以不要錯誤的以為每個程序員每天能寫8小時的程序。

            ● 你今天寫了這么多行代碼真有效率!編碼不是在掃地,比誰掃的面積大。不能單純用行數來評價開發人員的工作量。評判的標準應該結合模塊的復雜度,編碼的缺陷檢出量以及最終交付時可用代碼的比例(實踐表明,我們報廢了大量的無用代碼)。

            ● 他今天把自己100多個BUG都改了,我們得在組里表揚下他!在我看來這樣的領導不跟也罷,這就是讓人 相當無語的行為。好的開發者在提交測試前,覺得會對自己的代碼進行走查和調試,甚至使用單元測試工具,因此其代碼的缺陷檢出量很小。這樣的程序員,才值得 被表揚。而那個一天改了自己100多個BUG的人,作為管理者應該想想,流程哪里錯了,需要進行改進。

            ● 設計我來定,開發你閉嘴!這樣的例子也不少,這種做法有一種聽起來非常合理的理由——保證項目架構的概 念完整性。其解釋為,如果將設計人員從開發人員剝離,那么就可以將架構的概念完整性統一,因為設計人員的數量比開發人員是數量要少的多,更容易統一認識。 而這樣做的項目組,也默認地認為設計組的技術實力要明顯高于開發組。他們往往從開發組中選擇優秀的設計人員到設計組,但也會有走眼的時候。其一,硬手沒有 被提拔。這時候多半是硬手對設計不滿,并對團隊管理層產生質疑,并想法設法進行溝通。如果處理的好,可能硬手會被重視,如果溝通無門,那之后,可能會充斥 著抱怨和不滿,以及人際關系的惡化。有些強硬些的可能會選擇拒絕不合理的設計或更為極端的是離職。走眼的另一種情況是,挑的人干不了設計。這樣往往就是讓 他鍛煉,而不是撤換(彼得原理——每個人都會被晉升到他不適合的崗位)。這就郁悶到極點了,設計者將會與相應的數名開發人員進行一場曠日持久的暗戰。其 中,已經不只是個人的抱怨,甚至會演變成成員集體的士氣低落,并最終促成小組的重組。我認為,有必要將開發人員納入設計活動。應該參考開發人員的意見,其 原因有三:其一,開發人員對實現相當熟悉,往往發現設計中的不足;其二,通過授權開發者參與設計,能讓其感受到認同感,提升其參與項目的欲望,和責任心; 其三,讓開發參與設計,可以對設計人員進行儲備,在需要時作為備選資源使用。

            ● 客戶(領導)說必須完成,我也沒辦法!這就是“領導一句話,勞動人民跑斷腿!”這是非常典型的加班借 口。軟件構建過程如同耕種,你每次只處理它的一小部分,一點一點的加到整個系統,使系統一點一點的“生長”。這也暗示了,工作應該按部就班,正如春種秋收 一樣,各個環節有強硬的邏輯存在。所以,我們必須學會對不合理的要求說“不”。這里并不是說要拒絕客戶的需求,而是指應該向客戶說明情況并提出相應的備選 方案以供參考。例如通過通過削減范圍來達到按時完工的目的。PM需要向客戶說明情況,并向其提供幾套可行的解決方案,以促成項目向良性發展。

            ● 我是領導我來排進度!工作進度的安排不能是領導的單方決策,而應該參考做了解這項工作的人的意見。

            ● 系統上線了,項目就算結束了!只有當可交付成果成功移交,項目進行的相應的收尾工作,項目的經驗教訓文檔被總結和歸納,一個項目才算真正意義上的完成。

            (二)參考建議

            ● 做好前期準備。前期準備很重要,如果在開始構建之前認真的地進行適當的準備活動,那么項目會運作的良 好。充足的準備防止我們制造一個錯誤的產品。前期工作的好壞,多少會為這個項目的成功和失敗打下基礎。即使進入構建階段,如果我們發現前期工作做的不好, 也完全有理由退回去。前期準備工作和核心目標就是降低風險——一個好的項目規劃者能夠盡可能早地將主要的風險清除掉,以使項目的大部分工作能夠盡可平穩地 進行。目前,對后期影響最嚴重的風險是糟糕的需求分析和項目規劃,因此準備工作就傾向于集中改進需求分析和項目規劃。

            ● 預先行其事,必先利其器。用軟件武裝團隊提高生產效率,例如:版本控制,錯誤跟蹤,信息發布,自動發布,CASE工具,調試工具,測試工具,文檔管理,代碼生成工具等等。

            ● 分析項目類型,在管理和構建之間找尋平衡。商業系統、使命攸關的系統、性命攸關的系統在整個項目階段具備不同的控制粒度。需要根據項目的具體類型來確定管理的嚴謹程度,避免“過度控制”或“控制不足”。

            ● 需求必須被凍結。需求必須被凍結,如果需求不能凍結,那么誰來了都沒有用。再強的團隊也無法完成一個無盡的任務。

            ● 變更必須走流程。正確應對變更,變更并不可怕,可怕的是失控的變更。以下建議希望對讀者有所幫助:

            在構建期間處理需求變更

            1、核對需求,評估質量:如果需求不夠好,停下來,把它做好再開始。

            2、確保每一個人都知道需求變更的代價:讓客戶知道需求辦更并不像在Excel上進行幾個修改那樣容易,“進度”和“成本”是你最有力的武器。

            3、建立一套變更控制程序:固定的變更控制程序讓你知道在什么時候處理變更,讓客戶知道你會處理他們的提議。

            4、使用能適應變更的開發方法:迭代與增量。

            5、放棄這個項目:如果以上提議沒有一條奏效,需求變更極其頻繁,那么,評估你的項目,考慮放棄它吧,繼續下去你只會越陷越深。

            6、注意項目的商業案例:性價比,沒必要滿足超出項目成本的需求。

            ● 關于加班。做IT的加班是很正常的,但加班要加的有意義,而且不應該長期加班。必須針對關鍵路徑上的工 作進行趕工,而不是做些無法加快整體進度的工作。而且,應當安排調休,而不是支付加班費。其主要原因也是我不贊成加班的原因——疲勞更容易引人缺陷。加班 無疑會使人疲勞,每個人都想盡快結束手上的工作后回家休息。在長期疲憊的情況下,人員的工作效率會下降,士氣會低落,非正常離職率增加,最重要的是疲憊的 團隊很難保證軟件的質量,缺陷在不知不覺中引人,在后期無疑會為此付出代價。項目的總成本和周期,都會隨著引人缺陷的數量的增加而倍增,而且發現的越晚越 嚴重。

            ● 做好版本控制和配置管理。版本控制和配置管理是必須有的,即便是再小的項目也不能忽視,必須加以重視,一旦版本混亂,多多少少會對構活動造成影響。所以,平時不要偷懶,管理好每個基線。

          posted @ 2012-04-26 09:22 順其自然EVO 閱讀(193) | 評論 (0)編輯 收藏

          如何完成系統測試?

               摘要: 軟件系統測試意味著將軟件系統或者應用程序做為一個整體進行測試。應用程序的系統測試從整體上檢測軟件大致的業務,操作以及最終用戶需求的一致性。系統測試被歸類為黑盒測試?! ∵@就是為什么內部設計,架構或者代碼對于這種測試來說完全不重要?! ‘攬绦幸粋€軟件測試時,專業軟件測試員傾向于區分是接口里面的,還是整個軟件里面的錯誤或者缺陷。然而,當執行軟件或者應用程序的內建(build-in)測試的時候,專業的軟...  閱讀全文

          posted @ 2012-04-25 14:59 順其自然EVO 閱讀(189) | 評論 (0)編輯 收藏

          Java中類與類之間的關系

          Java中類與類之間的關系存在以下關系:

            1、泛化(Generalization)

            很簡單,就是我們常說的繼承。是說子類獲得父類的功能的同時,還可以擴展自己的功能。

            如圖:

            Java代碼中表現為:extends和implements

            2、依賴(Dependency)

            兩個相對獨立的咚咚(A和B),當A負責構造B時,A與B形成依賴關系,即A使用B。

            如圖:

            Java代碼中的表現為局部變量,方法的參數,以及對靜態方法的調用

            3、關聯(Association)

            兩個相對獨立的咚咚(A和B),當A對象持有B對象的時候,形成關聯關系。

            關于分為有兩種特殊的形式,聚合(Aggregation)和組合(Composition),聚合和組合只有概念上的區別,在Java中的代碼實現上沒有區別。

            聚合:指的是整體與部分的關系,如圖:

            組合:表示類之間整體和部分的關系,但是組合關系中部分和整體具有統一的生存期,即整體對象不存在,部分對象也將不存在,如圖:

            Java代碼中,表現為成員變量。

            4、總結

            在Java中,應該盡量優先使用組合,而不是繼承,因為繼承會使得類關系過于復雜化,破壞了封裝性,使用組合一樣可以獲得已有類的功能,而且會使新類更加穩固。

             實際上,從依賴 -----〉聚合--------〉組合,類與類之間的關系更加緊密,互相之間的影響越來越大,其實我們平常比較少去區分這些關系,而且事實上這東西的定 義不太好理解,所以肯定會導致認識上的偏差,所以我們使用這些東西的時候,盡量靠近大家都認同的做法,這樣容易讓別人理解。

          posted @ 2012-04-25 13:52 順其自然EVO 閱讀(167) | 評論 (0)編輯 收藏

          Oracle數據庫游標在存儲過程中的使用

          作為關系型數據庫市場的老大,Oracla占有舉足輕重的地位。雖然在操作上不如SQLSERVER那樣方便,但是他的強大的功能還是吸引來大批大批的追隨著。本人作為ORACLE菜鳥,在工作當中也偶爾使用Oracle。以下記錄的上由于工作需要寫的Oracle的<br>使用游標的儲存過程,個人覺得比較有代表性。希望給初學者一定的幫助,也給自己加深一下印象。

            在ORACLE中,他以一個語句塊為一個默認的事務。也就是說,如果你就單單只執行一段ORACLE的語句塊,他默認是以事務的形式執行的。

          CREATE OR REPLACE PROCEDURE sp_EditInlayOut(
                           FID     NUMBER,                    --修改記錄的ID T_INLAYOUT表的主鍵
                           InlayBoxIDs varchar2,          --修改的記錄
                           BoxCount number,              --裝箱數量
                           ApplyUserID varchar2,        --申請人編號
                           StoreUserID varchar2,         --庫管編號
                           ConfirmStatechar,              --確認狀態
                           ExistStatechar,                    --存在狀態
                           strErr OUT varchar2             --存儲過程執行結果。成功返回空,失敗返回錯誤原因
          )
          AS
             --定義變量
             v_Now DATE;                                     
             v_Now2 date;                                        
             v_LogID number;
             v_ChipID number;
             v_sql varchar2(2000);
          BEGIN
            
                --記錄日志
                INSERT INTO T_InlayOut_Log(F_InlayBoxIDs,f_Boxcount,f_Applyuserid,f_Storeuserid,f_Addtime,f_Confirmstate
                   ,f_Existstate, f_modifyid, f_modifytime, f_modifyuserid )
                                  ((SELECT F_InlayBoxIDs,f_Boxcount,f_Applyuserid,f_Storeuserid,f_Addtime,f_Confirmstate,f_Existstate
                                   ,FID,SYSDATE,StoreUserID FROM T_InlayOut WHERE F_ID=FID));
                --取剛插入記錄的ID
                select seq_t_inlayout_log.currval into v_LogID from dual;
                --定義游標
                 DECLARE CURSOR myCusor IS SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID IN (SELECT f_ID FROM 
                 T_InlayBox where F_InlayOutID = FID);
                --開始使用游標取數據
                 BEGIN
                      OPEN myCusor;
            
                      LOOP
                          FETCH myCusor INTO v_ChipID;
                          --游標取不到數據則退出
                          EXIT WHEN myCusor%NOTFOUND;    
            
                                SELECT MIN(F_CurrentTime) INTO v_Now FROM t_Chipstatehistory WHERE
                 (F_HistoryState ='Confirm_InlayIn') AND F_ChipID = v_ChipID;
                                --改變芯片表的狀態
                                UPDATEt_chip SET f_State ='Confirm_InlayIn',F_CompareTime = v_Now  WHERE F_ID = v_ChipID;
                                --保存芯片狀態歷史記錄
                                INSERT INTO T_CHIPSTATEHISTORY(f_chipid, f_Historystate,F_TABLEID,f_Currenttime,F_TABLENAME) 
                               VALUES
                                (v_ChipID,'Confirm_InlayIn',v_LogID,SYSDATE,'T_InlayOut_Log');
            
                      END LOOP;
                      CLOSE myCusor;
                 END;
            
                --選擇最近芯片狀態變更時間
                --SELECT MIN(F_CURRENTTIME) INTO v_NOW  FROM T_CHIPSTATEHISTORY WHERE F_HISTORYSTATE = 20 
                AND F_CHIPID IN (SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID=(SELECT F_ID FROM T_InlayBox 
                  WHERE F_InlayOutID=FID));
            
                --將芯片表中芯片狀態更新到以前狀態
                --UPDATE T_CHIP SET F_State=20,F_CompareTime=v_NOW WHERE F_InlayBoxID IN (SELECT F_ID FROM 
                 T_InlayBox WHERE F_InlayOutID =FID);
                --記錄芯片狀態變更日志
                --INSERT INTO  T_ChipStateHistory (F_ChipID,f_Historystate,f_Tableid,f_Currenttime,f_Tablename)VALUES
                --((SELECT F_ID FROM T_CHIP WHERE F_InlayBoxID=(SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID)),
                    20,v_LogID,SYSDATE,'T_InlayOut_Log');
            
            
                --將Inlay出庫箱表中以前的數據更新到以前狀態
                UPDATE T_InlayBox SET F_State=2,F_InlayOutID=nullWHERE F_InlayOutID =FID;
            
                --編輯時將新的INLAY出庫信息更新
                UPDATE T_InlayOut SET F_InlayBoxIDs=InlayBoxIDs,f_Boxcount=BoxCount,f_Applyuserid=ApplyUserID,
                f_Storeuserid=StoreUserID,f_Confirmstate=ConfirmState,F_ExistState=ExistState,F_ConfirmTime=null 
                WHERE F_ID=FID;
            
                --更新T_InlayBox 新的狀態
                --UPDATE T_InlayBox SET F_State=3,F_InlayOutID=FID WHERE F_IDin(InlayBoxIDs);
                v_sql :='UPDATE T_InlayBox SET F_State=3,F_InlayOutID='||FID||' WHERE F_ID in ('||InlayBoxIDs||')';
                 --立即執行v_sql
                EXECUTE IMMEDIATE  v_sql;
            
                SELECT SYSDATE INTO  v_Now2 FROM DUAL;
                --更新芯片表狀態
                UPDATE T_Chip SET F_State='No_Confirm_InlayOut',F_CompareTime=v_Now2  WHERE F_InlayBoxID IN
                 (SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID);
                --記錄當前操作日志
                INSERT INTO  T_ChipStateHistory (F_ChipID,f_Historystate,f_Tableid,f_Currenttime,f_Tablename) 
               SELECT F_ID,'No_Confirm_InlayOut',v_LogID,v_Now2,'T_InlayOut_Log'FROM T_CHIP WHERE F_InlayBoxID IN
               (SELECT F_ID FROM T_InlayBox WHERE F_InlayOutID=FID);
                 --提交
                 COMMIT;
               --發生異常時返回錯誤碼
               EXCEPTION
                  WHEN OTHERS THEN
                  strErr := substr(sqlerrm,1,100);
                  ROLLBACK;
          END sp_EditInlayOut;

            但是在SQLSERVER中,除非你將所有的T-SQL語句塊以顯示的方式【BEGIN TRANSACTION ....END TRANSACTION】申明在事務中,否則SQLSERVER會將語句塊中的每一句作為一個單獨的默認事務執行。

            此外,游標是一種比較占I/O資源的操作,使用完后應該及時關閉,以釋放系統資源。

          posted @ 2012-04-25 13:49 順其自然EVO 閱讀(1385) | 評論 (0)編輯 收藏

          SQL Server DBA工作內容詳解

           在Microsoft SQL Server 2008系統中,數據庫管理員(Database Administration,簡稱為DBA)是最重要的角色。DBA的工作目標就是確保Microsoft SQL Server 2008系統正常高效地運行。DBA的工作也是最繁忙的工作,無論是性能調整,還是災難恢復,都離不開DBA的支持。

            一般地,作為一個DBA,至少應該做好以下12項任務:

            ● 任務一:安裝和配置;

            ● 任務二:容量規劃;

            ● 任務三:應用架構設計;

            ● 任務四:管理數據庫對象;

            ● 任務五:存儲空間管理;

            ● 任務六:安全管理;

            ● 任務七:備份和恢復;

            ● 任務八:性能監視和調優;

            ● 任務九:調度作業;

            ● 任務十:網絡管理;

            ● 任務十一:高可用性和高可伸縮性管理;

            ● 任務十二:故障解決;

            下面簡單描述這些DBA的任務

            任務一:安裝和配置。

             DBA的第一項任務是安裝和配置Microsoft SQL Server 2008軟件系統,為順利使用Microsoft SQL Server 2008軟件創建良好的環境。無論是安裝還是配置,都應該根據實際需要來進行,使得系統滿足用戶的實際需求。需要注意的是,系統配置不是一勞永逸的,應該 隨時根據需求的變化和環境的需要,進行監視和適當地調整。

            任務二:容量規劃。

            容量規劃是對整個Microsoft SQL Server 2008系統進行一個總體的規劃。規劃的重點應該放在解決瓶頸問題上??梢詮膬热莺推谙迌蓚€方面考慮系統的容量規劃。

            從內容上來看,應該考慮的主要內容包括:硬件容量規劃、軟件規劃、網絡規劃。硬件容量規劃包括磁盤空間、CPU、I/O等規劃。軟件規劃包括操作系統的安裝和配置規劃、數據庫規劃、數據庫對象內容和數量規劃等。網絡規劃包括網絡硬件、網絡軟件和協議、網絡客戶數量流量和分布、網絡拓撲結構等規劃。

             從期限上來看,應該考慮短期、中期和長期規劃。短期規劃的目的是滿足當前日常業務的需要。中期規劃主要是滿足業務發展和擴大的需要。長期規劃主要是滿足 業務極限需要等。例如,如果預測某個系統的當前并發用戶數量是1000,3年后的用戶可能達到1000萬,那么這時既不能按照1000用戶的需求來設計, 也不能一下子按照1000萬用戶的需求來設計,一定要采取一個折中的形式。

            任務三:應用架構設計。

            應用架構設計包括數據庫設計、應用程序設計和相應的技術架構設計。

            數據庫設計應該考慮數據庫的邏輯需求、數據庫的創建方式和數量、數據庫數據文件和日志文件的物理位置等。一般情況下,可以在Microsoft SQL Server 2008系統成功安裝之后,根據規劃的目標,手工創建數據庫。

            應用設計應該考慮開發工具的選擇、API技術、內部資源和外部資源的結合、應用架構的分布等。需要強調是在應用設計時,DBA應該與開發人員共同工作,確保他們編寫出優化的代碼,盡可能地使用服務器的資源。

            技術架構設計主要包括表示層、邏輯層和數據層的分布。這些分布不應該考慮到硬件資源和用戶需求。既不能片面地追求過高的硬件資源,也不能僅僅局限于當前的環境,一定要按照可擴展的觀點來綜合考慮。

          任務四:管理數據庫對象。

            管理數據庫對象是使用數據庫的最基本、最重要的工作。這些對象包括表、索引、視圖、存儲過程、函數、觸發器、同義詞等。為了完成管理數據庫對象的工作,DBA應該能夠很好地回答諸如下面的這些問題。

            ● 系統應該包括哪些數據?

            ● 應該怎樣存儲這些數據?

            ● 應該在系統中創建哪些表?

            ● 應該在這些表中創建哪些索引,以便加速檢索?

            ● 是否應該創建視圖?為什么要創建這些視圖?

            ● 應該創建哪些存儲過程、函數、CLR對象?

            ● 應該在哪些表上創建觸發器?應該針對哪些操作創建觸發器?

            ● 是否應該創建同義詞?

            任務五:存儲空間管理。

            存儲空間管理任務就是怎樣為數據分配空間、怎樣保持空間可以滿足數據的不斷增長。隨著業務量的繼續和擴大,數據庫中的數據也會逐漸地增加,事務日志也不斷地增加。存儲空間管理任務主要圍繞下面幾個問題。

            ● 當前的數據庫由那些數據文件組成?

            ● 事務日志的大小應該如何設置?

            ● 數據的增長速度是多大?

            ● 如何配置數據文件和日志文件的增長方式?

            ● 數據庫中的數據何時可以清除或轉移到其他地方?

            任務六:安全管理。

            安全性是DBA重要的日常工作之一。安全管理的主要內容包括賬戶管理和權限管理。賬戶管理就是在數據庫中應該增加哪些賬戶、這些賬戶應該組合成哪些角色等等。權限管理是對象權限和語句權限的管理,應該回答下面這些問題:

            ● 這些賬戶或角色應該使用哪些對象?

            ● 這些賬戶或角色應該對這些對象執行哪些操作?

            ● 這些賬戶或角色應該在數據庫中執行哪些操作?

            ● 如何設置架構?如何建立架構和對象、架構和用戶的關系?

            任務七:備份和恢復。

            無論系統運行如何,系統的災難性管理是不可缺少的。天災、人禍、系統缺陷都有可能造成系統的癱瘓、失敗。怎樣解決這些災難性問題呢?辦法就是制 訂和實行備份和恢復策略。備份就是制作數據的副本,恢復就是將數據的副本復原到系統中。備份和恢復工作是DBA的一項持續性的重要工作,其執行頻率根據數 據的重要程度和系統的穩定程度來確定。

           任務八:性能監視和調優。

            根據企業的經營效益評價企業的管理水平,根據學生的考試成績評價學生的學習好壞。作為一個大型軟件系統,Microsoft SQL Server 2008系統的運行好壞必須得到正確地監視、評價和相應的調整。這是DBA的一項高級工作。借助一些工具和運行性能指標,DBA應該能夠監視系統的運行。 如果某些運行指標出現了問題,DBA應該及時地采取補救措施,使得系統始終保持高效運行狀態。

            任務九:調度作業。

            DBA不可能一天24小時不停地盯住系統的運行,及時地執行某些指定的操作。Microsoft SQL Server 2008系統提供了許多工具,DBA應該充分利用這些工具和機制,解決下面一些問題。

            ● 調度哪些作業應該由系統執行?

            ● 這些作業應該在何時執行?

            ● 如何確保這些作業可以正確地執行?

            ● 如果自動執行的作業執行失敗時,應該如何處理?

            ● 如何使得系統可以均衡地執行相應的操作?

            任務十:網絡管理。

            作為一種分布式的網絡數據庫,網絡管理的任務更加的重要。Microsoft SQL Server 2008系統提供了網絡管理工具和服務,DBA應該借助這些工具進行服務規劃和管理網絡操作。

            任務十一:高可用性和高可伸縮性管理。

            作為一個DBA,必須保持系統具有高可用性和高可伸縮性??捎眯允且豁椂攘坑嬎銠C系統正常運行時間的指標??缮炜s性描述應用程序可以接受的并發 用戶訪問的數量問題。影響系統可用性的主要因素包括:網絡可靠性、硬件故障、應用程序失敗、操作系統崩潰、自然災害等。無論是數據庫系統管理員,還是應用 程序設計人員,都應該最小化系統破壞的幾率,最大化系統的可用性。在設計系統的可用性時,應該確定采取什么樣的可用性策略來滿足可用性的需求。

            可用性的需求可以通過3個方面描述,即運行的時間、連接性需求和數據的緊密和松散要求。在確定可用性的需求時,首先考慮系統的運行時間。一般 地,數據庫應用程序有兩種運行時間,即在工作時間是可用的和在任何時間都是可用的。如果只是要求在工作時間是可用的,那么可以把系統的維護等工作安排在周 末進行。但是,有許多應用程序要求每天運行24小時、每周運行7天,例如,在線超市等,這時必須采取措施保證系統總是運行的。不同的應用程序有不同的連接 性要求。大多數的應用程序和電子商務解決方案要求采用可靠的網絡連接。這時,要求永久性的在線連接,必須最小化各種異常現象的發生。有些應用程序允許用戶 離線使用。這時,系統的可用性要求降低了。大多數應用程序要求數據是同步使用的。用戶對數據的請求,系統必須立即做出回應。這是緊密型的數據要求,這種情 況必須保證系統的高可用性。有些應用程序不需要數據是同步的,對用戶的請求可以延遲回應。這種要求是數據松散型的要求,這時系統的可用性需求比較低。

            任務十二:故障解決。

            雖然不希望Microsoft SQL Server 2008系統出現故障,但是故障可能是無法避免的。這些故障可能每天都會發生。有些故障是人為不小心造成的,有些故障可能是系統中的缺陷形成的,有些故障 可能是莫名其妙的。作為一個DBA,在系統中的其他用戶心目中是Microsoft SQL Server系統的權威。無論是大事還是小事,DBA都應該做到迅速診斷、準確判斷、快速修復。從這個意義上來說,DBA是一個數據庫系統的專業醫生。

          posted @ 2012-04-24 16:47 順其自然EVO 閱讀(167) | 評論 (0)編輯 收藏

          【工具】ANT的安裝和配置(windows)

          1、下載:到ANT官方網站http://ant.apache.org/下載最新版本,解壓后即可。
          2、配置環境變量:我的電腦----屬性-----高級----環境變量
                如:ANT_HOME:C:\apache-ant-1.7.1
                PATH:%ANT_HOME%\bin (為了方便在dos環境下操作)
          3、查看是否安裝成功:在dos窗口中輸入命令ant,若出現結果
             Buildfile:build.xml does not exist! 
             Build failed
             說明ant安裝成功!因為ant默認運行build.xml文件,這個文件需要我們建立。 
          4、使用:
          (1)在D盤根目錄下建立build.xml
          1<?xml version="1.0" encoding="GBK"?>
          2<project name="測試腳本" default="copyfile" basedir="." >
          3   <target name="copyfile">
          4      <copy file="d:/a.txt" todir="e:/Temp" overwrite="true" />
          5   </target>
          6</project>

          (2)在D盤根目錄下建立文件a.txt。
          (3)進入dos,
                   d:
                   ant
                   
                   此時可在E:/Temp目錄下見到文件aa.txt,內容與a.txt一樣,即拷貝成功! 

          好了現在我們測試下安裝:點擊 開始——運行——(輸入cmd)——確定,在DOS窗口下輸入 ant -version 命令,如果出現圖1所示的畫面,那么恭喜你ANT安裝成功!

          posted @ 2012-04-24 11:59 順其自然EVO 閱讀(2070) | 評論 (1)編輯 收藏

          Windows下SVN的安裝與配置

          STEP 1:下載和安裝

          首先在Subversion的官方網站http://sourceforge.net/projects/win32svn/files/ 
          去下載windows安裝包,最新版。
          下載后安裝在本地機器上,這里注意的是最好將安裝目錄指定為純英文名目錄,安裝在中文目錄下天知道哪天會冒出一個讓你想破頭也想不出的錯誤來。
          下載TortoiseSVN進行本地安裝,http://sourceforge.net/projects/tortoisesvn/files/ 
          這是一個將SVN集成到windows shell中的GUI管理工具,推薦使用。

          STEP 2:創建儲存庫

          安裝完TortoiseSVN后提示要重啟機器,其實啟不啟都可以正常使用了,首先創建SVN儲存庫(repository),可以選擇命令行方式或者通過TortoiseSVN插件進行GUI操作,命令行運行如下:

          svnadmin create E:\svn

          e:\svn就是我指定的儲存庫目錄,如果用GUI方式,可以在這個目錄下點擊右鍵選擇[TotoiseSVN]->[Create Repository href...]進行創建,版本庫模式指定為默認的即可。
          repository創建完畢后會在目錄下生成若干個文件和文件夾,dav目錄是提供給Apache與mod_dav_svn使用的目錄,讓它們存儲內部 數據;db目錄就是所有版本控制的數據文件;hooks目錄放置hook腳本文件的目錄;locks用來放置Subversion文件庫鎖定數據的目錄, 用來追蹤存取文件庫的客戶端;format文件是一個文本文件,里面只放了一個整數,表示當前文件庫配置的版本號;

          STEP 3:配置

          打開/conf/目錄,打開svnserve.conf找到一下兩句:

          # [general]
          # password-db = passwd
          去之每行開頭的#,其中第二行是指定身份驗證的文件名,即passwd文件
          同樣打開passwd文件,將
          # [users]
          # harry = harryssecret
          # sally = sallyssecret
          這幾行的開頭#字符去掉,這是設置用戶,一行一個,存儲格式為“用戶名 = 密碼”,如可插入一行:admin = admin888,即為系統添加一個用戶名為admin,密碼為admin888的用戶

          STEP 4:運行SVN服務

          在命令行執行

          svnserve --daemon --root E:\svn
          服務啟動,--daemon可簡寫為-d,--root可簡寫為-r,可以建立一個批處理文件并放在windows啟動組中便于開機就運行SVN服務,或者在這個地址http://clanlib.org/~mbn/svnservice/下載那個svnservice.exe文件,拷貝到E:\svn\bin目錄下,再從命令行下執行:
          svnservice -install --daemon --root "E:\svn\Repository"
          sc config svnservice start= auto
          net start svnservice
          此文件會將SVN變成windows系統的一個服務,并默認為自啟動,注意:執行第三句時確保前面以命令行方式運行的SVN服務已經停止,如果沒停止可在其窗口中按Ctrl+C中止運行。

          STEP 5:創建項目版本樹

          確定SVN服務(命令行或windows服務)運行后,在你需要導入儲存庫的目錄下單擊右鍵選擇[TortoiseSVN]-> [Import...],在彈開的窗口的URL框中輸入 "svn://localhost/myproject" 點擊 "OK" 執行導入,如果沒有報錯,數 據就全部加入SVN儲存庫目錄樹上了。用命令行也可以完成這些操作,這需要你在系統變量中新建一個“SVN_EDITOR”的系統變量,變量值為本地的一 個文本編輯器執行文件路徑,一般指到windows的記事本上就行了 "c:\windows\notepad.exe" ,然后新開一個CMD窗口,執行

          svn mkdir svn://localhost/myproject

          隨即關閉記事本打開的log文件窗口后按"c"鍵繼續后生成項目樹。一般情況,我們在創建文件根路徑后應該在創建三個目錄:branches、tags、trunk,這三個目錄是Subversion需要的三個目錄。對于check out、commit、update等操作可以通過svn命令行方式執行,也可以用TortoiseSVN的windows菜單完成,非常簡單咯。

          posted @ 2012-04-24 11:24 順其自然EVO 閱讀(835) | 評論 (0)編輯 收藏

          Ubuntu 安裝subversion(svn)權限配置

          1.安裝
          2.創建項目目錄

          $ sudo mkdir /home/jack/svn
          $ cd /home/jack/svn
          $ sudo mkdir myproject
          $ sudo chmod -R ugo+rws myproject (讓你的文件夾都在不同的用戶下均有權限,這里你自己可以配置,就不多說了)

          3.創建SVN文件倉庫
          $ sudo svnadmin create /home/jack/svn/myproject (創建一個庫,到時apache修改虛擬路徑指向此/home/jack/svn/myproject)

          4.下面的命令用于將項目導入到SVN 文件倉庫:

          svn import -m "New import" /var/www/ file:///home/jack/svn/myproject/(可以將虛擬路徑的web放入導入myproject, 這里的/var/www

          是不帶svn的純程序)

          5.訪問方式及項目導入:
          $ svn co file:///home/jack/svn/myproject
          或者
          $ svn co file://localhost/home/jack/svn/myproject (apache虛擬如果指向本地即可用此句)
          * 注意:
          如果您并不確定主機的名稱,您必須使用三個斜杠(///),而如果您指定了主機的名稱,則您必須使用兩個斜杠(//).


          6.修改配置文件
          在cd /home/jack/svn/myproject/conf/目錄下有三個文件:
          svnserve.conf 是svn的配置文件
          authz 是設置用戶權限的配置文件(可自定義文件名,在svnserve.conf的authz-db = authz中指定)
          passwd 是設置用戶名和密碼的配置文件(可自定義文件名,在svnserve.conf的password-db = passwd中指定)

              vi svnserve.conf
              修改如下:
              [general]
              anon-access = none
              auth-access = write
              password-db = passwd
              authz-db = authz

              vi authz
              修改如下:
              [/]
              jackgroup = jack
              #給myproject倉庫添加一個名稱為jack的用戶,權限為可寫。
              vi passwd
              jack = 123456

          7.啟動svn
             ps ax | grep svn 或 ps -ef | grep svn (查看svn進程)
             kill 2003(先終止進程)
             啟動:
             svnserve -d -r /home/jack/svn/myproject/

          8.在客戶機安裝svn客戶端

          1、下載地址:
           http://code.google.com/p/rails4scm/downloads/detail?name=tortoisewin32svn.msi
          2. 右擊svn checkout
          svn://xxx.xxx.200.22/
          就可以了.

          posted @ 2012-04-23 17:03 順其自然EVO 閱讀(1365) | 評論 (0)編輯 收藏

          僅列出標題
          共394頁: First 上一頁 334 335 336 337 338 339 340 341 342 下一頁 Last 
          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 贵溪市| 柯坪县| 西藏| 兰溪市| 十堰市| 榆树市| 西平县| 黄浦区| 元氏县| 淮北市| 南雄市| 吉隆县| 安达市| 普定县| 桓仁| 大港区| 延长县| 南涧| 鄂温| 江门市| 鹿泉市| 师宗县| 旺苍县| 神农架林区| 郑州市| 公主岭市| 唐山市| 渝中区| 佛坪县| 嵊州市| 南华县| 朝阳县| 纳雍县| 准格尔旗| 于田县| 库伦旗| 高陵县| 井冈山市| 桃江县| 台中县| 杭锦旗|