1、軟件工程_成功案例1卡拉 OK 點播系統 項目名稱： 項目名稱：卡拉 OK 點播系統； 項目功能： 項目功能：適合酒吧，歌廳等小型的場所使用的小型局域網卡拉 OK 點播系統； 項目成功經驗： （1）目標明確 該項目目標明確是該項目成功的一個關鍵因素。 一開始， 在與客戶方面經過友好地 溝通，使得項目目標清晰定義，即在小型的局域網中使用的卡拉 OK 點播系統?；诿?確目標定義，為以后的開發工作，包括需求分析，計劃制定，人員任務分配等等都給予 了極大的方便。很明顯，在一個項目開始時，明確好整個項目的目標是很重要而且是必 要的。 （2）開發人員經驗豐富 很明顯，開發人員的開發經驗豐富與否，決定著整

2、個項目的進度，質量，甚至成功 與否。在該項目中，幾個開發人員開發經驗豐富，都有過一到兩年的開發經驗，其中兩 個甚至有開發過類似的項目的經驗。 后來的事實也證明， 正是由于開發人員的豐富經驗， 極大地促進了整個項目的進度，以及質量。 （3）文檔的完備 在我國，軟件工程危機的一個很大的原因在于，沒有形成及時保存文檔的習慣。往 往，一個項目結束了，可是文檔就那么幾份，甚至連最基本的需求分析，計劃大綱都不 清楚。在進行該項目的過程中，項目經理充分注意了這個問題。明確要求，小組開發人 員在完成完一天的工作，一個任務單元時必須完成文檔的總結。有了這些文檔，為項目 后期的測試工作起了很大的作用。2遠程醫療保

3、健系統 項目名稱：遠程醫療保健系統。 項目功能： 項目功能：實現醫療服務的遠程實現。 項目成功經驗： （1）小組分工明確 這個項目的人員不是很多， 只有四個， 如何充分利用有限的項目小組人員是很重要 的。該項目中，項目經理對小組的開發人員進行了明確的分工，在項目開發的一系列環 節中都進行了人員的安排，例如， 需求的定義，計劃的制定，代碼的編寫， 功能的測試， 客戶的聯系等。完備的而又明確的小組分工，有利于項目的順利運行。 （2）充分調動開發人員的積極性 該項目正是調用了開發人員的積極性， 充分激發了開發人員的開發熱情， 發揮了開 發人員的以往經驗， 從而使得項目在開發人員不是很多的情況下， 保

4、質保量地完成了整 個項目的開發工作。 3.項目經理管理得當（財務，人事，風險,時間） 項目經理是一個項目的靈魂。 其能力的強弱， 經驗的豐富與否直接影響到了項目的 開發。該項目中，項目經理是一個有著豐富的 IT 管理經驗的人員。在財務的管理，人 事的計劃，時間的安排等方面的良好，是該項目成功的一個很重要的因素。3.城域網綜合資源管理系統 項目名稱：城域網綜合資源管理系統。 項目功能： 項目功能：有效的管理網絡資源，包括歌曲，電影，課件，新聞，提高網絡資源的利用率。 項目成功經驗： （1）需求分析清晰 需求定義，是整個軟件工程的基本前提。沒有一個良好的，明確的，清晰的項目需 求，開發工作的缺陷是

5、顯而易見的。為此，公司在需求定義方面花了大氣力。專門派了 一個人員與客戶經常保持聯系。 使得客戶的一件能夠很及時地反映到軟件設計中。 整是 由于這樣， 使得該項目在客戶鑒定時很容易就通過了， 完全減少了后期的需求變動的麻 煩。 （2）與客戶保持溝通 很明顯，需求是很重要的。如果需求不明確，或者需求經常變動，會影響項目的開 發工作。而需求的明確與否，又與跟客戶的溝通密切相關。與客戶及時有效的溝通，有 利于客戶及時的理解，建議，修改項目的功能和質量，也減少了到了項目開發后期，由 于需求的變動，從而導致項目失敗的危險性。該項目中，項目經理花了很大的時間與客 戶保持聯系，了解客戶需求，這對項目的益處是

6、顯而易見的。 （3）跟蹤項目 為什么要跟蹤項目？有沒有這個必要性？是不是一種時間的浪費？這個項目的成 功充分地說明了這個問題。答案是肯定的。有必要進行項目的跟蹤。這個項目開發人員 有限，開發資金也不是很充足，而且加上開發周期短，技術難度大等因素使得這個項目 的開發難度極大。但是，由于以前公司開開發過類似項目，同時與以外項目的客戶又有 經常的溝通， 及時幫助客戶進行項目維護。 這些都為理解該項目的功能背景， 技術背景， 專業背景具備了良好的環境。可以說，該項目的成功實施，是離不開前期對以外類似項 目的跟蹤的。軟件工程_失敗案例4數據語音網絡系統 項目名稱：數據語音網絡系統 項目功能：滿足家庭用戶

7、和集團用戶的語音業務及寬帶數據業務的需求 項目失敗教訓： 項目失敗教訓： A 領導不力 由于領導的不力，導致了小組在堅持計劃和個人約束方面出問題。雖然有能力的領 導是對領導角色的基本的要求，但是，能力是多方面的，包括知識框架，社交技巧， 領導技巧，溝通技巧，風險估計等等都是對領導的要求。領導的能力直接決定了整 個項目的整體質量。 B 時間無限制拖延 時間上的無限制拖延也是該項目失敗的原因之一。原本兩個月的開發計劃，結果由 于開發小組的效率低下，導致了整個項目時間上的無限制拖延。 C 質量低下 軟件質量的低下，無疑也是項目失敗的關鍵原因。由于軟件質量的低下，導致了項 目測試階段的工作量的復雜，最

8、終導致了項目開發的失敗。5郵政資信管理系統 項目名稱：郵政資信管理系統。 項目功能： 項目功能：管理郵政方面業務的監督和管理，提高郵政的服務效率。 項目失敗教訓： 項目失敗教訓：A需求內容不明確，把握不充分這是我們經常遇到的問題。一方面，由于客戶（需求方）IT 知識缺乏，一開始自己也 不知道要開發什么樣的系統，或者懶于系統地整理出來，經常是走一步算一步，不斷地 提出和更改需求，使得實現方叫苦連天。另一方面，實現方由于行業知識的缺乏和設計 人員水平的低下，不能完全理解客戶的需求說明，而又沒有加以嚴格的確認，經常是以 想當然的方法進行系統設計，結果是推倒重來。因此，需求分析必須注重雙方理解和認 識

9、的一致，逐項逐條地進行確認。 B工數估算過少 軟件開發的工數估算是一項很重要的工作，必須綜合開發的階段、人員的生產率、工作 的復雜程度、歷史經驗等因素，將一些定性的內容定量化。對工數的重要性認識不足， 經常用拍腦袋的方式草算，是最常見的問題。還有，軟件開發經常會出現一些平時不可 見的工作量，如人員的培訓時間、各個開發階段的評審時間等，經驗不足的項目經理經 常會遺漏。同時，還有如下一些原因也是很典型的： （1）出于客戶和公司上層的壓力在工數估算上予以妥協。例如，客戶威脅要用工數更 少的開發商，公司因經營困難必須削減費用、縮短工期，最后只能妥協，寄希望于員工 加班。 （2）設計者過于自信或出于自尊

10、心問題，對一些技術問題不夠重視，或者擔心估算多 被嘲笑。 （3）過分憑經驗。由于有過去的成功經驗，沒有具體分析就認為這次項目估計也差不 多，而沒有想到這次項目可能規模更大、項目組成員更多、素質各異、新員工很多，而 且是一個新的行業。 C項目組織過小 每個公司都希望以最少的成本完成項目， 人手不足是大多數項目都會面臨的問題。 還有 一種情況是項目組成員的技術水平達不到項目的要求， 公司只能提供這些分配好的技術 人員，或者由于項目經理的失誤，在項目工數估算時沒有明確要求技術水平，寄希望于 員工自己努力。還有一些項目經理認為，在項目啟動時不需要高水平的技術人員。 開發計劃不充分 沒有良好的開發計劃和

11、開發目標，項目的成功就無從談起。開發計劃太粗略，主要反映 在以下幾個方面： （1）工作分擔（責任范圍）不明確，工作分割結構（WBS）與項目組織結構不明確或 者不相對應，各成員之間的接口不明確，導致有一些工作根本無人負責。 （2）每個開發階段的提交結果定義不明確，中間結果是否已經完成，完成了多少模糊 不清，結果是到了項目后期堆積了大量工作。 （3）開發計劃沒有指定里程碑或檢查點，也沒有規定設計評審期。 （4）開發計劃沒有規定進度管理方法和職責，導致無法正常進行進度管理。 3企業客戶資料管理系統 項目名稱： 項目名稱：企業客戶資料管理系統。 項目功能： 項目功能：負責企業自身的客戶的資料的管理，分

12、析，提取，提出實用方案。 項目失敗教訓： 項目失敗教訓：A設計能力不足 項目組設計人員能力的低下是項目失敗的原因之一。 一方面， 由于對技術問題的難度未 能正確評價，將設計任務交給了與要求水平不相稱的人員，造成設計結果無法實現。另 一方面， 隨著資源外包現象的日益普遍， 一些公司經常因工期緊而匆忙將中標的項目部 分轉包給其他協作公司， 這些公司的設計能力如不加仔細評價， 就會對整個項目造成影 響。 B項目經理的管理能力不足 沒有及時把握進度。項目經理自己也不知道項目的狀態，下屬人員報喜不報憂，害怕報 告問題后給自己添麻煩。 進度管理必須隨時收集有關項目管理的數據， 開發人員總是擔 心管理工作會

13、增加自己的工作量，不愿配合。管理人員甚至不知道應該收集哪些數據。 由于沒有進行定期的項目評審報告會， 表面上進展順利而實際上隱藏著危機。 管理人員 總是輕信下屬的報告而沒有加以核實。 出現嚴重問題時，管理人員沒有根據現階段狀況重新評價需求分析結果、工數估算、設 計結果等就匆忙采取頭痛醫頭、腳痛醫腳的措施，致使問題更嚴重。4電子印花分色系統 項目名稱： 項目名稱：電子印花分色系統。 項目功能： 項目功能：該系統集計算機、激光、電子等高科技技術于一體，支持高速、高質量圖像生成 與編輯和印花工藝處理，是一套穩定性高、功能完備、易于擴充、操作快速簡便的已達到國 際先進水平的開放式電子印花分色系統，是國

14、內唯一集樣稿掃描，花樣設計與編輯，云紋處 理，連曬輸出等多功能于一體的具有自主版權的集成化系統 項目失敗教訓： 項目失敗教訓： A開發商和客戶的關系 本來開發商和客戶之間是軟件產品的提供者和使用者之間的關系,一個賣東西,一個買東 西,兩者之間的關系是平等的,公平交易,童叟無欺,這才是兩者之間的正常合理的關系,可 是現在呢? 現在開發商和用戶之間的關系是嚴重不平等的,開發商為了得到訂單,往往委屈求全,放 棄自己應該堅持的原則,在競標時相互壓價,甚至采用某些不夠光明正大的手段來得到訂 單,自己把自己放到了一個被動的地位.許多開發商都有這樣的口號"以客戶為中心",他 們不僅是這樣

15、說的,而且也是這樣做的,問題是,一種不平等的關系,能夠長期堅持下去嗎? 我從網上看到說,某個項目競標,某開發商提供的標書有一大箱子,需要兩個人才能抬到 會場上.請問,這種標書有誰會看呢?難道開發商連這點起碼的常識都沒有了嗎?既然沒有 人看,那么為什么要寫呢?難道開發商真的以為客戶會傻到不知道你在欺騙他嗎?那么寫 這種標書欺騙的是誰呢?恐怕是自己欺騙自己吧! 開發商怕得罪客戶,卻沒有認識到有時和客戶沖突是不可避免的,客戶怕開發商來欺騙自 己,于是一次一次進行試探,開發商越讓步,客戶越認為自己受到了欺騙.開發商的讓步往 往換不來客戶的信任,而是換來了客戶的更加不信任.由于開發商自己不相信自己,自己

16、 欺騙自己,最后也無法得到客戶的信任. 畢竟軟件開發是由開發商來完成的,那么就應該也必須由開發商來決定項目的進展和內 容,可是現在卻往往由于客戶的壓力而妥協,放棄自己的原則,這樣來做軟件開發,能成功第 （4） 頁 共 5 頁2010-11-11軟件工程案例分析 嗎?失敗是必然的,成功才是僥幸.曹亮 010552018結論就是,在軟件開發中,應當以開發商為中心,而不是以客戶為中心,客戶的意見只是參 考和借鑒,而不是金科玉律,不應該害怕和客戶發生沖突,而應該分析沖突產生的原因,把 沖突看成問題的征兆,而不是單純來消除沖突本身. B銷售人員和技術人員之間的關系 一個人擔任的角色不同,他考慮問題自然會

17、更多考慮到自己的切身利益,至于這樣做可能 會給同事帶來的麻煩,就管不了那么多了.在開發商內部,銷售人員和技術人員之間的關 系也非常奇特.在許多公司,為了提高銷售人員的工作積極性,對銷售人員采用提成的方 式進行獎勵,而將底薪定得很低,這樣一來,銷售人員為了拿到項目的訂單,往往會屈從于 客戶的壓力,許下許多難以兌現的諾言,或者由于對于技術的不了解而隨意答應客戶的要 求.等到合同簽訂完畢,進入項目開發階段時,客戶會拿這些諾言來要求開發人員進行兌 現,結果是開發人員非常被動,對銷售人員怨氣沖天,于是告訴客戶這些要求無法滿足,而 客戶也勃然大怒,你們這些人怎么一拿到錢就變了臉了呢?問題就是,由于銷售人員

18、不考 慮技術人員將來的實現,從而許下了過高的諾言,這樣做的結果也許可以拿到訂單,可是 由于銷售人員和技術人員的口徑不一樣,最后客戶無所適從,感到自己受到了欺騙,接著 將一腔怒火發到了技術人員頭上,兩者之間的合作和信任關系逐漸變成了對抗和欺騙的 關系. 銷售人員和技術人員應該是一個自行車的兩個輪子,他們的關系必須是相互合作,相互支 持的,而不應該是互相拆臺,相互對抗的,一旦他們之間相互對抗,那么就會給整個公司的 聲譽帶來災難性的后果. C項目管理者和開發人員之間的關系 項目管理者和開發人員之間的關系,本來應該是相互團結,相互幫助,共同面對問題的關 系,可是許多項目管理者把這種關系扭曲成了管理與被管理的強制性關系,用種種規章制 度,種種管理方法來強迫開發人員接受,把自己放到了開發人員的對立面,和開發人員離 心離德,甚至還美其名曰"量化管理,科學管理".在這種糟糕的管理下,開發人員沒有任何 辦法,要么被動接受糟糕的管理,要么辭職以抗議.一旦一個項目發生了這種情況,它想成 功就非常難了. 這種問題原來并不明顯,現在隨著各種 MBA,印度經驗,軟件工廠等似是而非的理論的泛 濫,許多人,尤其是許多根本不懂軟件開發的管理者,更加變本加歷,用近乎苛刻的手段來 加強對