第一篇：軟件測試外包揭秘 - 我是一個二手的程序員! - ITeye技術網(wǎng)站

軟件測試外包揭秘ITeye技術

網(wǎng)站

這里主要是以赴IBM測試工程師為例，微軟,HP等其他外企的測試外包也都大同小異。1.測試外包的分類 測試外包可以分為兩種：

一種是甲方公司將項目完全包給乙方公司，由乙方公司完全出人力物力，在乙方所在地完成項目；

一種是甲方公司“借用”乙方公司的員工，同甲方員工一起在甲方公司完成項目項目。

凡是赴某某外企工程師的職位都是屬于后者。2.IBM為什么要做測試外包？

可以降低成本和風險，在IBM工作的人分為Regular和Contractor（也稱為Vendor），Regular是IBM正式員工。Contractor是合同工，就是我們所說的外包。Contractor不按IBM工資標準，也不享受IBM薪酬福利。假如08年的經(jīng)濟危機真的影響到了中國，IBM大可以釋放一部分Contractor來降低成本，而不需要裁自己的正式員工。（好在這件事情對IBM China并沒有任何影響），此外，Contractor的各種保險都是由乙方公司也就是外包公司負責的，所以出現(xiàn)什么事情的話，也是由外包公司負責，IBM不需要承擔風險。3.Contractor屬于IBM員工么？

完全不屬于，跟Contractor有關的只是外包你到IBM的外包公司。4.薪酬

其實無論你去哪家外包公司，IBM給外包公司的錢都是固定的。你的薪水和福利待遇，完全看外包公司對你的“剝削程度”。外包公司扣掉給你交的四險一金，運營成本，想要的利潤以后，剩下的就是你的工資了。所以，只要你會侃價，去哪家外包公司都一樣，工資都會達到一個統(tǒng)一的水平。大概范圍是：6500+ 到 8500+，至于怎樣從6到8，就全評你個人的專業(yè)技術和經(jīng)驗了，這點還是相當?shù)墓健?.福利 在此說明一點，無論去哪家外包公司，4險一金的基數(shù)也不會是按照100%來交的，比如你的薪水是7k，那么公司會按照一定的系數(shù)來給你交4險一金，有的是按照30%，有的是按照50%。這個才是挑選外包公司的關鍵。因為有些公司表面給的工資很高，但實際上，4險一金給上的很少，這樣的話，其實未必有工資低但福利待遇好的公司劃算。因為工資高的話，相應的扣的個人所得稅也多了，而如果公司將這部分錢交了住房公積金醫(yī)療保險等，這些錢是不需要繳稅的，并且你交個人住房公積金醫(yī)療保險的同時，公司也是要按照比例交這部分錢的。6.做外包測試的優(yōu)點 做外包測試的優(yōu)點不少

第一，你可以接觸到很多其他公司接觸不到的軟硬件產(chǎn)品。比如在IBM，所有的軟件我們都是可以在內(nèi)網(wǎng)中使用的，而AIX，IBM小型機等等，也都很容易搞到。而在微軟，我的一個朋友是做Windows7測試的，在微軟還沒正式發(fā)布以前，這些很玄的東東他們就可以上手，這個真是讓人羨慕。第二，可以跟同事學到很多技術。在這種大型外企中，你接觸到的同時不是名校的博士就是名校的碩士，海歸等等，如果想跟他們學點什么的話，沒有人會對知識吝嗇。第三，會有一些培訓。先不說Team的內(nèi)部同事之間的互相培訓，在平時每隔一段時間，也會有很多其他Team的同事會做一些新技術的培訓講座，這些講座只要你有時間，都是可以去聽的。7.做外包測試的缺點

缺點一：做任何事情不可能沒缺點的，做外包測試，最大的缺點就是缺少所謂的歸屬感。因為打你入職那天起，就是在甲方公司工作的，平時根本不需要回外包公司。很多人說看著旁邊不是Regular就是其他外包公司來的Contractor，會覺得沒有歸屬感。很多外包公司在這方面做出了努力，比如在你過生日的時候，外包公司會給你訂一個大蛋糕送過來；每逢過節(jié)都送一些禮品和購物券；組織春游秋游等等。至于這些事情能不能增加歸屬感，就是仁者見仁，智者見智的事情了。缺點二：很多開源產(chǎn)品在公司是不允許使用的（例如Hibernate,主要就是因為它需要遵循的開源協(xié)議），而很多外面平時很常用的軟件也沒機會再使用（比如MySQL，在IBM一般都用DB2 or Derby）缺點三：對IBM產(chǎn)品產(chǎn)生依賴性會比較麻煩。很多Contractor在IBM都會用Rational Application Developer或者是Rational Softeware Architect，因為它們的功能實在是太強大了。不過我一般還是選擇用Eclipse，因為我怕離開IBM的時候，外面沒公司買得起這些軟件。缺點四：很少有白盒測試。如果你一心想來這些外企做白盒測試，我覺得希望會比較渺茫，因為China這邊很少有代碼，所以做白盒測試的可能性就小了很多。最多是有時會針對一些API來用JUnit來寫一些代碼。缺點五：做性能測試的不多，如果你以前是用LR等工具做性能測試的，那么來到這里會沒用武之地（可以去HP做外包，LoadRuner是屬于它的，我朋友在那里不但會常用，還會有免費培訓），因為IBM的性能測試要么是自己寫一些腳本，要么就是用Rational Performance Tester。缺點六：不要以為在IBM就會都用功能自動化測試，其實大部分工作都是黑盒手工測試。Rational Function Tester用的機會很少。不過每個Team發(fā)展都后期，都會自己寫一點Automation Tools，來盡量簡化自己的勞動，Shell，Bat腳本，Java程序等等。8.加班

這點是我覺得做外包測試做爽的事情，因為在外企，根本很少加班。（強烈推薦那些加班加得傷心的人來這里療傷）更爽的是早晚上下班并不需要刷卡，雖然我們也有門卡，但是純粹是用來開門的，早晚都不需要太在意時間，當別人8點55分在馬路上狂奔的時候，你可以悠閑的走著。加班的情況也有兩種：

一是項目特別特別緊，而你又沒辦法按時干完活，這個時候你就可以選擇晚上晚走一點，加一會班。（其實每天需要干多少活是從項目一開始Leader就分配好了的，每天需要自己安排，Leader只會在項目快結束的時候才會關注你剩下多少活沒有干，所以一般我都選擇第二天多干點，堅決按點吃飯呵呵）

再就是跟老外開電話會議，而開會時間是他們的早晨。這種情況的話，需要在公司等到8點半（這段時間是自由的），也就是他們上班，然后開1個小時的會。不過這種電話會議完全可以回家用家里的電話撥免費400上去去聽。9.技能要求

不要瞧不起我們這幫被“人販子”賣掉的人，其實做外包測試，需要的技能還是很高的。很多自稱“精通SSH的高手”，就連外包公司的筆試第一關都過不去。但也不要將測試外包想得太難。想做外包測試工程師，無外乎需要滿足一下幾個條件：

1.本科學歷（這個是最低要求，如果是碩士被錄取的希望更大點）

2.2年以上Java開發(fā)或者Java相關項目測試經(jīng)驗 3.Java基礎（相信混Javaeye的這個都沒問題）4.有測試相關的經(jīng)驗

5.最好會使用一些Linux基本命令 10.是否有轉正的機會 很多人都關心這一點，問是否干了一段時間之后，就轉為Regular。轉是肯定有轉的，但不是每個人都能轉，主要看個人的機遇和能力。一般干外包干個2，3年，都會考慮這件事情，要么Team覺得你是有用之才，就留下轉了，要么就繼續(xù)晃蕩著，直到你自己選擇走人。11.為什么是外包測試，不是外包開發(fā)

其實也是有外包開發(fā)的職位的，只不過比較少而已。這種大型外企，一般的coding都放在的國外，所以即使是Regular，也是測試工程師居多。一時間只想到了這么多，如果有朋友對哪些問題還有疑問，歡迎回帖，我會以Q&A的方式貼到原文中補充。

第二篇：程序員如何承接軟件外包項目,你是怎么做判斷的呢

程序員如何承接軟件外包項目，你是怎么做判斷的呢

隨著現(xiàn)在外包的軟件項目不斷增長，但隨之而來的，承接外包的軟件公司、軟件團隊也越來越多，包括很多個人SOHO一族也加入到承接軟件的競爭行列中來 了，因此現(xiàn)在對于軟件項目的爭奪也很激烈。有很多人不知道上哪里去爭取項目，總是抱怨沒有項目做；也有的人雖然編程技術不錯，但是對于與客戶談項目卻是一 竅不通，結果應該拿到的項目也拿不到手；也有的雖然已經(jīng)接到了項目，卻發(fā)現(xiàn)在實施開發(fā)的時候遇到好多從來沒有遇到過的問題。作為一個多年從事外包項目接單 的軟件開發(fā)人士，我想從以下幾方面談談我的經(jīng)驗，希望對大家會有所幫助。第一點，到哪里接項目

軟件團隊或SOHO最為關心的一點是在哪里可以找到項目做，也就是到哪里可以找到有外包需求的客戶。對于一般人來說，廣交朋友然后通過熟人介紹還是 接項目的第一途徑，但這要求你的朋友或熟人要在企業(yè)或公司里有比效重要的管理位置，對于像那些每天只能是埋頭寫代碼的程序員這顯然是不太現(xiàn)實的。所以大家不能等著項目來找你，而是要主動的出擊去找項目。

現(xiàn)在網(wǎng)上有很多軟件外包網(wǎng)站，在這里你可以找到不少的軟件外包信息。比如GAF(即Get A Freelancer-是目前國外最流行的外包站點)上就有大量的軟件外包信息。不過這里每天外包的項目雖然很多，但競爭也很激烈。一般一個外包信息發(fā)出后一天內(nèi)就會有無數(shù)個競爭者（很多印度阿三在和你拼報價），所以能第一時間與客戶取得聯(lián)系是非常關鍵的。因為客戶一般都是先入為主的，一般來說，如果第一個談項目的人他覺得滿意 了，就會對其他的競爭者不再予以考慮，所以你要經(jīng)常上網(wǎng)站上看看有什么最新的項目，并立即與項目的發(fā)包方取得直接的聯(lián)系。其他比如Elance、GetACoder、ScriptLance、匯新云等上也有很多外包的信息，大家可以自己上去看看。

是不是第一個聯(lián)系了客戶就高枕無憂了呢？也不完全是這樣的。前面說過了，一個項目總是有很多人去競爭，就算是你搶先聯(lián)系了客戶，但可能后來又有不少 人也同樣聯(lián)系了他，而客戶在這種情況下一般是處在比較猶豫的情形之中，這時，你就要經(jīng)常不斷地聯(lián)系客戶，不斷地征詢客戶的意見，詢問客戶的項目需求，把你對項目的理解也經(jīng)常與客戶交流。這樣，客戶會覺得你比較有誠意來接這個項目，就會比較傾向于把項目交給你來完成。有時，與客戶拉拉家常，也會拉近你與客戶 之間的距離。說不定你會意外發(fā)現(xiàn)客戶原來還是你的老鄉(xiāng)，那就更好談了?？傊绻阆胍霠幦〉巾椖?，就要經(jīng)常不斷地與客戶保持聯(lián)系，直到最終達成意向。第二點，如何與客戶談需求

接項目最重要的一步是與客戶談需求?？蛻魧浖男枨笫琼椖恳?guī)劃和實施的根本，所以在與客戶談需求時，一定要讓用戶將所有的想法盡可能的闡述清楚，并把所有的要求羅列出來。這時候不應該害怕“勾引”起客戶的潛在需求而增加設計開發(fā)的工作量。而應該直接明白地要客戶把項目的要求一條條地列出來。這時先把條理、歸納、分析先都扔到一邊去，用紙筆將用戶最原始、最完整的要求準確地記錄下來。假如項目在你對客戶的需求沒有完全了解清楚的情況下就匆匆上馬，那么就會隨時發(fā)生意想不到的變更，輕則使項目延期或超出預算，重則使得原來已經(jīng)做好的軟件要徹底推倒重來。

所以我們在實施項目之前應該深入了解和挖掘客戶需求，對某些不明確的需求要與發(fā)包方反復進行討論，對于項目實施過程中的需求變更要規(guī)定處理辦法，并 形成項目的最終需求。在需求分析階段，接包方首先對發(fā)包方的需求認真分析，然后通過業(yè)務建模、會談、問卷、需求會議等方式收集客戶完整需求，形成文檔，然后經(jīng)過客戶討論、客戶審查、文檔修訂等多次反復的過程。有一點需要注意，即使雙方談的很投緣，在討論需求時也一定要詳細周到，精確到每一條不能再劃分的軟 件功能為止。要消除客戶的疑慮-作為客戶，他對于項目的承接者總是存在各種疑慮。比如，這個項目究竟承接方有沒有能力開發(fā)啊？項目組人員是否有這方面的經(jīng)驗？是否作過類似的產(chǎn)品，是否有這方面的技術能力？會不會只是騙了預付款就開溜啊？最后完成的項目能不能達到自己的要求啊？我們作為承接者，就是要千方百計打消客戶的這種疑慮。比如，你要經(jīng)常準備好一些成功的案例和以前的項目的DEMO，就是把你以前成功完成過的項目，做成一個DEMO給客戶看，讓他覺得你是有能力完成類似的項目的。俗 話說，事實勝于雄辯，把你以前做過的類似的項目DEMO給他看，好過你一遍遍空口的承諾。因為軟件開發(fā)的過程中誰也不能保證一點問題不出，相比較而言，一 個有經(jīng)驗的開發(fā)人員會更容易得到客戶的信任。因為你已經(jīng)有和客戶的項目功能接近的案例，無疑會縮短開發(fā)周期，技術上有更好的保障，因此客戶也更樂于把項目 交給你。所以，程序員平常必須多花點時間和精力，搜集整理以前自己做過的項目案例，并把它們分門別類地整理出來，遇到同類項目的客戶，就可以給客戶進行演 示，這樣客戶就會放心把項目交給你了。另外，把團隊組成人員、技術能力、經(jīng)驗等客戶看重的東西整理出來并給客戶看，也能夠對爭取到項目起很大的作用。

第三點，如何合理地報價

在完全了解客戶的需求后，下一步就是要確定一個合理的報價。接包方要從跟客戶的交談中盡量地了解出客戶的準確意思，思考客戶想要的是怎樣的一個軟 件，項目復雜的程度多大，客戶的要求有多高，客戶的性格如何，能夠接受的價格范圍等等，這些因素對于軟件項目的報價都是密切相關的。如果客戶要的是一個小 型的軟件系統(tǒng)，不太苛求有多全面的功能，只要滿足某一方面的需要，并且客戶又是一個比較隨和的人，那么項目可以報一個接近成本的價格；相反如果客戶要求的 是一個面面俱到的管理系統(tǒng)，需要有各方面的功能，缺一不可，并且客戶又是那種對項目要求嚴格苛刻，絕不變通的人，那就要充分考慮各種不穩(wěn)定的因素，報一個比較高的價格。

在很多的情況下，客戶在跟接包方談項目之前，心理都已經(jīng)有一個價格底線。如果要投入的費用超過了客戶的預算范圍，客戶將不再與你談該項目，他會轉而 找其它軟件團隊商談。所以跟客戶談項目的過程中要迅速地思考客戶需求的真正含義，能夠通過某種轉換和變通，把客戶對于技術的要求與自己團隊的技術力量可以 接受的價格相對比，從而得出一個雙方都能接受的報價。在與客戶的談判當中，靈活變通是成功的關鍵之一。當然并不是所有的客戶都可以通過變通而滿足，遇到客 戶不認同項目費用的情況一定要處之泰然，真誠地為客戶解釋，把客戶的需求細化為技術上的要求給他分析，讓他同意你的報價的合理性。即使客戶對編程技術不是 很了解，但經(jīng)過你的細致的分析后也會對你的報價表示認同的。第四點，如何組織團隊

由于客戶的需求是不同的，因而項目也是各種各樣的。有網(wǎng)站設計項目、也有軟件設計項目，要求使用的編程語言也是多種多樣的。即使是在一個項目中，比如說網(wǎng)站制作的項目中，也有著前臺的美工設計和后臺程序的編寫的分工。這些工作如果全部交給一個人去作那是絕對完成不了的。即使是一個小的團隊，也不能保證所有的人才都齊備。因此最好就是自己把項目初步設計好，然后找合作伙伴共同開發(fā)，自己總體掌握整個項目的全部進度。如果在身邊沒有好的合作伙伴的話，網(wǎng)上也能找到不少可以合作的伙伴。

第五點，如何能收到項目款 這是整個項目中最后也是最難的一個環(huán)節(jié)。即使你的項目做得再好，如果沒有收到款，那你前面的一切努力都等于是零。要想項目能順利地收到款項，那么從項目未開始之前的談判階段就要對這一點加以注意。首先要判斷對方是否是真心外包項目。這里有幾點經(jīng)驗拿來給大家分享一下：如果你看到項目中說 “請?zhí)峁┩暾慕鉀Q方案和成功案例發(fā)到某某郵箱”，這應該只是想套取設計方案而已，發(fā)幾張你們公司或團隊的推介廣告和報價單給他即可。還有的客戶張口就要 源碼要設計文檔設計方案的，這種人目的性太強了，如果你真給了他就再也不理你啦。還有的外包方死活不肯介紹自己，不肯告訴自己是誰、怎么稱呼、怎么聯(lián)系、是什么公司、做什么業(yè)務的，與這種連最基本的誠信都沒有的客戶就根本沒有必要談下去。其次是判斷對方是否有充足的資金和實力，項目要求是否合理(技術、周 期等各方面)。這個可以在需求的談判中可以有意識地來加以探明，如果對方的項目很大卻老是強調(diào)項目非常簡單，這應該是不想付足項目款；有的發(fā)包方堅持不肯給預付款，老是要求項目完成后再交全部款項，這應該是沒有誠心付款。還有的項目要30天才能完成卻只給幾天的開發(fā)時間，這種項目外包方也是很值得懷疑的。

對于軟件團隊或個人SOHO族來說，由于不是公司，對方對于我們的信任度不會很高，所以對于大的項目一定要采用合同方式，這樣出現(xiàn)問題才好解決。在合同中，最好訂清楚分階段來付款，這樣有利于分散風險。比如，一般要求合同訂好后先交30%的定金，項目進行到一半后待客戶驗證后交50%的項目款，全部項目完成并交付后再交清全部款項。這樣做對于客戶來說也比較好控制項目的進度，因此對方也比較容易認同并接受。以上談了軟件團隊或個人在承接軟件項目時應該注意的幾個關鍵問題，其實還有很多問題由于文章的篇幅所限沒有涉及。比如對于項目的選擇，有的人大的項 目做不來，小的項目又不愿做。結果到頭來什么項目都承接不到。因此一開始要把自己的期望值放低一些，先從一些幾百元的小項目做起，有了一定經(jīng)驗后再接一些 大項目，這樣循序見進才能不斷進步。

第三篇：代碼審查是由若干程序員和測試員組成一個審查小組

代碼審查是由若干程序員和測試員組成一個審查小組，通過閱讀、討論和爭議，對程序進行靜態(tài)分析的過程。代碼審查分兩步。第一步，小組負責人提前把設計規(guī)格說明書、控制流程圖、程序文本及有關要求、規(guī)范等分發(fā)給小組成員，作為審查的依據(jù)。小組成員在充分閱讀這些材料后，進入審查的第二步，召開程序審查會。

走查與代碼審查基本相同，其過程分為兩步。第一步把材料先發(fā)給走查小組每個成員，讓他們認真研究程序，然后再開會。開會的程序與代碼審查不同，不是簡單地讀程序和對照錯誤檢查表進行檢查，而是讓與會者“充當計算機”，即首先由測試組成員為被測程序準備一批有代表性的測試用例，提交給走查小組。走查小組開會，集體扮演計算機角色，讓測試用例沿程序的邏輯運行一遍，隨時記錄程序的蹤跡，供分析和討論用。

------------------

我們把代碼審查叫做CR，即Code Review。它是項目進展到編碼階段非常重要的品質(zhì)保證活動。但是很多時候，我們的CR工作都流于形式，在CR過程中不能發(fā)現(xiàn)本質(zhì)問題，主要有以下四點原因：

一，CR時的目的性不強，缺乏針對性。CR的根本目的是保證品質(zhì)，但不能把它做為一次CR活動的直接目標，這樣的目標太泛泛，讓我們在CR活動過程中抓不住重點。二，CR活動時參與的角色不合理。參與CR活動的人大多是技術合格，但業(yè)務不合格，這樣對于一些復雜的業(yè)務邏輯問題就很難發(fā)現(xiàn)，從而使得這些業(yè)務邏輯問題在CR的保護傘下，堂而皇之的蒙混過關。

三，CR活動過于集中，一次CR的代碼量太大。在有限的幾個小時內(nèi)，面對上千行，甚至更多的代碼時，再有耐心的人也難免產(chǎn)生視覺疲勞。

四，準備不足，對于要CR的代碼缺少必要的審查規(guī)范和標準。在代碼審查過程中，我們往往只有代碼編寫規(guī)范，但是代碼的設計規(guī)范、業(yè)務的邏輯規(guī)范和標準等準備不足。那么，我們應該怎樣做，才能使CR工作保質(zhì)而且高效呢？一個標準的CR活動應該分為三個階段：

一，事前準備階段。在一次CR前，以下對以下內(nèi)容進行充分準備。

1．CR的對象。在準備CR代碼對象時，我們要注意代碼的數(shù)量，如果代碼量比較大，要對代碼進行必要的分解，確定其中的關鍵代碼，對關鍵代碼進行CR，可以達到舉一反三的目的。

2．CR內(nèi)容。我們對代碼的審查內(nèi)容很多，如代碼的編寫是否規(guī)范（注釋的書寫格式、命名規(guī)范等）、技術處理規(guī)范（異常處理、日志處理、代碼組織結構等）、業(yè)務實現(xiàn)等。我們不能希望通過一次CR活動，完成所有這些內(nèi)容的審查，因此我們必須設定本次CR活動內(nèi)容界限，確定審查重點；

3．評審規(guī)范和標準。在CR前設計確定評審規(guī)范和標準是必要，通過規(guī)范和標準我們在審查過程中可以有據(jù)可依，有理可循，而且還可以做到標準統(tǒng)一。

4．選擇CR活動的參與者。在CR開始前，必須把本次CR活動的對象、審查內(nèi)容以及審查的規(guī)范和標準通報給所有的參與者。

5．選擇CR活動的實施方式。CR活動有很多形式可供我們選擇，我們可以根據(jù)實際情況選擇桌面式CR、演示講解式CR、一對一的座位CR等等。

二，實施階段。充分的事前準備，只是做好CR活動的前提，在CR實施過程中，我們要做好以下工作。

1．準確記錄。對于CR過程發(fā)現(xiàn)的問題，我們必須清晰準確的記錄，可以使用問題點

記錄單，明確記錄的項目和內(nèi)容。

2．CR過程中，要采用代碼作者講解和審查者提問方式。審查者不能只在發(fā)現(xiàn)問題時提問，同時也要根據(jù)本次審查的內(nèi)容要求代碼作者對某個特定問題的講解。

3．對事前確定的審查內(nèi)容，要逐項審查，不能因為時間不足等因素一掃而過。

4．實施審查時，要營造一個討論問題、解決問題的氛圍，不能把審查會搞成批判會，這樣會影響相關人員的積極性。

三，事后跟蹤跟蹤。CR結束后，對發(fā)現(xiàn)的問題，首先需要確定以下內(nèi)容。

1．問題點的難易程度以及影響的范圍；

2．解決問題的責任者和問題點修正結果的確認者；

3．解決問題點的時限。

其次是對于修正問題責任者，在問題點的修正過程中，要三方面內(nèi)容的記錄。

1．問題點的原因；

2．解決問題點的對策；

3．修正的內(nèi)容。

做為修正結果的確認者，必須按照事前約定的時限及時的對修正結果進行全面的確認。工作流管理系統(tǒng)是“一種在工作流形式化表示的驅動下，通過軟件的執(zhí)行而完成工作流定義、管理及執(zhí)行的系統(tǒng)”，其主要目標是對業(yè)務過程中各活動發(fā)生的先后次序及同活動相關的相應人力或信息資源的調(diào)用，進行管理而實現(xiàn)業(yè)務過程的自動化。

在企業(yè)的日常工作中，絕大多數(shù)屬于流程類工作，比如業(yè)務的分級審批工作、各類申請表單、公文簽審、業(yè)務處理等。通過現(xiàn)代的技術手段將企業(yè)內(nèi)諸多繁瑣復雜的業(yè)務流程自動化，并對其進行有效地管理便是工作流需要解決的問題。

傳統(tǒng)的系統(tǒng)設計方式將業(yè)務流程以編碼的方式固化在應用系統(tǒng)中，在業(yè)務流程和組織結構發(fā)生改變的情況下，需要將系統(tǒng)進行重大修改，甚至重新設計。實際上，業(yè)務流程的改變是導致許多應用系統(tǒng)失敗的最主要的原因。

工作流管理系統(tǒng)的出現(xiàn)使得上述情況發(fā)生了改變。應用系統(tǒng)的開發(fā)人員通過可視化的方式分析和設計業(yè)務流程，并將各個應用模塊聯(lián)接在一起。在組織結構和業(yè)務流程發(fā)生變化的時候，能夠在很少修改甚至不修改原來應用的情況下，僅僅通過適當調(diào)整或重新定義工作流程就能適應變化了的情況。

采用工作流管理系統(tǒng)有以下優(yōu)點：

提高系統(tǒng)的柔性，適應業(yè)務流程的變化，建設各類信息系統(tǒng)的重要工作之一就是發(fā)現(xiàn)用戶的工作流程，進行分析建模，并把它體現(xiàn)到信息系統(tǒng)的設計中。

企業(yè)都在隨著時間不斷地改革工作流程，使企業(yè)各部門能夠更好地發(fā)揮服務職能、提高工作效率。

-------------------------代碼審查（code review）是軟件開發(fā)過程的一個階段，在這個階段中，代碼創(chuàng)造者和審查人員，可能還有質(zhì)量保證（QA）測試人員，一起進行代碼審查。能在該階段中就找出并更正存在的錯誤，相對來說比較合理，因為如果在開發(fā)軟件后面的階段或者軟件交付給用戶后才來處理、查找和修改程序缺陷的話，會花費更多成本。

審查人員需要很仔細地檢查代碼，包括：

? 缺陷或者潛在缺陷

? 和整個程序設計的一致性

? 評論的質(zhì)量

? 遵守編碼標準代碼審查通常能很好地檢測出安全漏洞問題。有一些專門的應用程序可以幫助進行代碼審查。自動代碼審查系統(tǒng)可以有效地系統(tǒng)化地檢測源代碼的潛在問題，如緩沖區(qū)溢出、競態(tài)條件、內(nèi)存泄露、代碼塊大小問題和重復語句等。另外，代碼審查也常用于檢測補丁質(zhì)量。安全代碼審查的目的是要識別出會導致安全問題和事故的不安全編碼技術和漏洞。雖然可能很耗時，但代碼審查必須是項目開發(fā)周期中的常規(guī)事件，這是因為在開發(fā)時修復安全缺陷會比以后在產(chǎn)品部署或維護修復周期中再做這項工作節(jié)省大量的成本和工作量。

代碼走讀與審查

目的主要檢查軟件代碼編寫質(zhì)量，是否與設計相符，與開發(fā)目的（需求）是否一致；是否符合編碼規(guī)范；有沒有存在明顯的缺陷；

與測試的不同是測試通過一系列的測試活動(運行程序為主)來發(fā)現(xiàn)BUG，而代碼審查走讀則一方面通過瀏覽代碼，檢查語法結構，調(diào)用關系，以規(guī)范度，注釋率，類化程度，耦合度，復用度等等指標來衡量代碼的質(zhì)量，達到防范問題發(fā)生；另一方面檢查代碼與設計的偏差，問題是否得到正確解決。

代碼審查的階段

一般的代碼審查活動通常發(fā)生在軟件完成時提交測試前，主要的目的是檢查軟件代碼結構，評估軟件質(zhì)量，防止軟件出現(xiàn)重大缺陷，把質(zhì)量問題解決在測試之前。

近年來隨著軟件行業(yè)的發(fā)展，軟件開發(fā)設計和控制能力不斷提高，但軟件依然存在BUG，不停地發(fā)放補丁，問題依然存在。對軟件測試后的修改，也越來越謹慎，考慮得也越來越周全，因此，修改bug的代碼改動也越來越重要，軟件行業(yè)開始對代碼修動進行了走讀和審查，目的是防止問題的再次發(fā)生并且防止修改引發(fā)新的問題。