A. 從技術和管理方面談談如何提高軟體的可維護性
建立明確的軟體質量目標和優先順序
一個可維護的程序應是可理解的、可靠的、可測試的、可修改的、可移植的、效率高的和可使用的。但要實現這所有的目標，需要付出很大的代價，而且也不一定行得通。因為某些質量特性是相互促進的，例如可理解性和可測試性、可理解性和可修改性。但另一些質量特性卻是相互抵觸的，例如效率和可移植性、效率和可修改性等。因此，盡管可維護性要求每一種質量特性都要得到滿足，但它們的相對重要性應隨程序的用途及計算環境的不同而不同。
2使用提高軟體質量的技術和工具
模塊化是軟體開發過程中提高軟體質量，降低成本的有效方法之一，也是提高可維護性的有效的技術。它的優點是如果需要改變某個模塊的功能，則只要改變這個模塊，對其他模塊影響很小；如果需要增加程序的某些功能，則僅需增加完成這些功能的新的模塊或模塊層；程序的測試與重復測試比較容易；程序錯誤易於定位和糾正；容易提高程序效率。使用結構化程序設計技術，提高現有系統的可維護性。採用備用件的方法，當要修改某一個模塊時，用一個新的結構良好的模塊替換掉整個模塊。這種方法要求了解所替換模塊的外部(介面)特性，可以不了解其內部工作情況。它有利於減少新的錯誤，並提供了一個用結構化模塊逐步替換掉非結構化模塊的機會。採用自動重建結構和重新格式化的工具(結構更新技術)。採用如代碼評價程序、重定格式程序、結構化工具等自動軟體工具——把非結構化代碼轉換成良好結構代碼。改進現有程序的不完善的文檔。改進和補充文檔的目的是為了提高程序的可理解性，以提高可維護性。採用結構化小組程序設計的思想和結構文檔工具。軟體開發過程中。建立主程序員小組，實現嚴格的組織化結構，強調規范，明確領導以及職能分工，能夠改善通信、提高程序生產率；在檢查程序質量時，採取有組織分工的結構普查，分工合作，各司其職，能夠有效地實施質量檢查。同樣，在軟體維護過程中，維護小組也可以採取與主程序員小組和結構普查類似的方式，以保證程序的質量。
3進行明確的質量保證審查
質量保證審查對於獲得和維持軟體的質量，是一個很有用的技術，還可以用來檢測在開發和維護階段內發生的質量變化。一旦檢測出問題來，就可以採取措施來糾正，以控制不斷增長的軟體維護成本，延長軟體系統的有效生命期。為了保證軟體的可維護性，有4種類型的軟體審查。
在檢查點進行復審。保證軟體質量的最佳方法是在軟體開發的最初階段就把質量要求考慮進去，並在開發過程每一階段的終點，設置檢查點進行檢查。檢查的目的是要證實已開發的軟體是否符合標准，是否滿足規定的質量需求。在不同的檢查點，檢查的重點不完全相同。如圖1所示。
驗收檢查。驗收檢查是一個特殊的檢查點的檢查，是交付使用前的最後一次檢查，是軟體投入運行之前保證可維護性的最後機會。它實際上是驗收測試的一部分，只不過它是從維護的角度提出驗收的條件和標准。
周期性地維護審查。軟體在運行期間，為了糾正新發現的錯誤或缺陷，為了適應計算環境的變化，為了響應用戶新的需求，必須進行修改。因此會導致軟體質量有變壞的危險，可能產生新的錯誤，破壞程序概念的完整性。因此，必須像硬體的定期檢查一樣，每月一次或二月一次，對軟體做周期性的維護審查，以跟蹤軟體質量的變化。周期性維護審查實際上是開發階段檢查點復查的繼續，並且採用的檢查方法、檢查內容都是相同的。為了便於用戶進行運行管理，適時提供維護工具以及有關信息是很重要的。
維護審查的結果可以同以前的維護審查的結果、以前的驗收檢查的結果和檢查點檢查的結果相比較，任何一種改變都表明在軟體質量上或其他類型的問題上可能起了變化。對於改變的原因應當進行分析，例如，如果使用的是復雜性度量標准，則應當隨機地選擇少量模塊，再次測量其復雜性。
對軟體包進行檢查。軟體包是一種標准化了的，可為不同單位、不同用戶使用的軟體。軟體包賣主考慮到他的專利權，一般不會提供給用戶他的源代碼和程序文檔。因此，對軟體包的維護採取以下方法。使用單位的維護人員首先要仔細分析、研究賣主提供的用戶手冊、操作手冊、培訓教程、新版本說明、計算機環境要求書、未來特性表，以及賣方提供的驗收測試報告等，在此基礎上，深入了解本單位的希望和要求，編制軟體包的檢驗程序。該檢驗程序檢查軟體包程序所執行的功能是否與用戶的要求和條件相一致。為了建立這個程序，維護人員可以利用賣方提供的驗收測試實例，還可以自己重新設計新的測試實例。根據測試結果，檢查和驗證軟體包的參數或控制結構，以完成軟體包的維護。
B. 計算機技術因素如何改進
計算機應用技術是指利用可以利用的任何一種計算機軟體的功能,為人們提供一定的服務。從廣義的層面將,所謂的計算機應用技術,就是計算機的所有軟體的所有功能給人們生產生活等帶來的變化與積極影響。本文將從我國計算機應用技術現狀入手,闡述計算機應用技術的發展及出現的問題,提出一定的改進措施。
C. 軟體如何用CMMI改進過程
軟體過程改進是一種含有大量管理成分的工作技術它主要包括以下三個關鍵步驟：a)對比目前的狀態和期望達到的狀態，找出存在的差距；b)確定要改變哪一些差距，要改變到什麼程度；c)制定相應的具體的實施計劃，其中的「具體」是指：1）要有明確的可以檢驗的目標；2）要定出檢驗成功與否的標准；3）要有具體的實施辦法；4）指定具體執行計劃的人，並明確具體的職責與任務；5）
要明確執行計劃的主要領導或協調者，以負責解決在計劃執行中出現的問題；6）要列出「實施計劃」用的新技術與新工具以及如何獲得這些新技術與新工具。
D. 軟體維護的不足與改進方式
咨詢記錄 · 回答於2021-10-21
E. 如何提高軟體研發的效率
1、提高代碼的規范性。編碼規范 可以提高代碼的可讀性，並且在代碼修改的時候很容易。
2.對功能進行分類，並拆分。分析出幾種處理邏輯。編寫代碼時，部分代碼可以。可以提編碼速度。
3.對功能進行分類，並合並。提出共通類。
4.不同的package對應不同的功能。
簡單的說，每天寫幾百行代碼。堅持半年或者1年，就知道什麼方式是適合你的了。 不寫代碼，光想，十年也還是那個水平。每個人的邏輯思維是不一樣的，寫代碼的方式也是不一樣的。有時間問，還不如多寫寫。或者，自己模擬現實個場景（或公司管理制度之類的），然後實現。寫幾個，很自然的就知道自己該怎麼寫了。
F. 軟體進一步改進思路
軟體還在完善之中，還需更多的工程實踐加以對比分析，從而進一步細化軟體模型的推導，提高軟體預測的准確性。具體的改進思路如下：
1）鑽遇角和「車輪效應」運用非線性計算，提高模型預測精度；
2）考慮井身結構、地層擴徑系數等因素對井眼軌跡的影響，提高預測精度；
3）與可視化編程語言LABview結合使用，進一步改善軟體界面友好性，使界面美觀化、人性化；
4）軟體功能擴展，例如：根據設計井眼軌跡和預測軌跡，給出更合理的鑽進工程參數以及泥漿性能參數等，使其對鑽井施工有一定的指導意義；
5）數據錄入和結果輸出更方便快捷，預測成果展示方式更豐富；
6）軟體中嵌入資料庫技術，加強數據成果管理能力，科學挖掘使用數據成果，獲得更有價值的鑽井技術數據。
G. 軟體過程改進的五條原則
SPI的五條核心原則分別是：
1·注重問題 2·強調知識創新3 ·鼓勵參與 4·領導層的統一 5·計劃不斷地改進。
「問題的解決是過程改進的核心，實踐不僅是SPI組的目標也是它的起點。」這條原則為過程改進人員指明了目標，明確了方法。SPI就是要在實踐中發現軟體過程中的問題，並在實踐中尋找和找到解決問題的辦法，可以說過程改進就是在不斷發現問題和解決問題的過程中不斷向前發展。
「改進是一種知識的創新，SPI是受知識的驅動的」。這條原則強調了知識創新在SPI中的作用，提醒了SPI人員在注重知識創新的同時更要注重知識的傳播和擴散。
通常從事SPI工作的做法是，過程改進僅僅是過程改進人員的事情，其他人員只是被動地接受。而「合作促使改進產生」這條原則給予了我們很好的啟發和提示。它告訴我們，過程改進不僅僅是一個人或幾個人的事情，而是整個組織的事情。只有鼓勵大家都積極參與，讓這些人基於自身的經驗和職業的判斷力來實實在在地設計和開發新的過程，才能使設計出來的過程真正為他們所理解，為他們所用，從而實現過程的成功。這也是我們在過程改進工作中容易疏忽的地方。
「SPI的關鍵點在於改變軟體開發的方式。然而，改變人的行為並不是件容易的事。」這條原則分析了我們在這項工作中可能會遇到的困難和阻力，本書中也不忘為我們提供了如何克服這些問題的可行方法、建議和實例。
「改進必須是綜合了各個層次的人的力量。」SPI人員一定要保證SPI的目標與組織的整體目標是一致的，因為只有這樣才能保證SPI工作得到各個領導層的贊同、支持和投入，才能綜合利用各個層次的力量來推動SPI工作的前進。這是預防過程改進項目風險的重要手段。
「改進應該是一個不斷持續的過程。」這一原則進一步提示和告誡SPI人員一定要認識到改進的不斷持續的特性。到達頂點並不重要，關鍵的是，你現在處在一個上升??達一個目標你就創造了另一個更高的目標，這個目標對我們的過程和環境都具有重要的意義。
這五條原則是從實踐中發展而來、相互關聯的SPI哲學，對我們SPI工作具有非常重要的指導作用。
H. 軟體過程改進的策略
重診斷，輕評估 以診斷和解決企業實際問題為SPI方法論，不追求商業評估。以往實施ISO9000的過程中發現，企業拿證書的願望常常會沖淡「真正改進」的目的。所以，除非不得已，建議一開始不要把商業評估作為目標，以便將焦點集中在「改進」上。的確，一旦進行商業評估，難保不急功近利，限期取證。SPI如同「治病」，多長時間治好怎麼可以人為規定呢？
重診斷，正是前述自底向上方法論的具體貫徹。根據企業的不同狀態和症狀，實施有針對性的方案，將有望設計出實用性更強、效率更高的應用模型。
重實施，輕宣傳 我們不妨來看一組數據，這是北京SPIN去年發起的一次調查，提問是「您認為軟體企業中開發不規范，不能突破管理瓶頸的原因是什麼？」
可見，以往我們多年來實施ISO9000這樣的體系，但效果差得可憐（客戶滿意度12%）。
據報道，中國通過ISO9000的企業超過了日本和韓國，但是中國並沒有因此成為質量強國！
ISO9000在軟體企業的現狀，並不能僅僅歸結於ISO9000不適合軟體企業這一點上，更大的問題在於，人們對體系的「可實施性」研究和重視得不太夠。
所以我們提出以高的「過程實施率」（定義的文檔被很好的遵守）和「過程性能改善」為SPI目標，不追求宣傳效應。 實施制度化的同時，並行實施企業文化；既要施壓，又要清障。
中小企業往往制度化體系很不健全，存在著隨意決策的管理習慣，甚至基本的企業紀律都不具備，企業還處於「人治」和「法制」的爭論中，這樣的狀態和某些大企業實施SPI的狀況是不同的，需要特別強調行政施壓。由於缺乏統一的企業文化，所以理念的統一也要加以重視。
CMM的實質是制度化體系，實施CMM也是實施全面制度化的有效途徑。但是制度和組織文化總是辨證存在的，沒有良好的文化保障，制度化將困難重重，而沒有制度的支撐，文化也將是無源之水。企業文化的實施從改造企業價值觀開始，價值觀是企業文化的核心，一個企業中如果好的行為不能得到鼓勵，壞的行為不能得到懲罰，那怎麼能倡導出有利於制度生存的價值觀呢？
兩手抓還包括另外一個層次的含義，過程改進要加強推進和減少阻力並重。這針對兩種現實中的錯誤認識：一種認為，員工都是自覺的，只要把道理講清楚了，制度就能得到實施。這種假定是不現實的，如同法律，如果假設人們都是遵紀守法的，那麼法律本身就沒必要存在了。實際情況是，人們在組織中總是有區分的，有的人主動順應變革，有的人推一推也能動，有的人可能推十下也不動，從而成為變革的障礙。所以變革的落實需要一個強的「推力」。另外一個觀點剛好相反，認為沒必要對員工講為什麼，只要告訴怎樣做就行了。這又走到另外一個極端，體系在強力的推動下可能會暫時得到執行，但是由於並沒有解決觀念轉變的問題，一定難以持久。 要推行配置管理工具和項目管理工具這兩種工具，工具將有效分解事務性工作，從而緩解人力資源投入不足的矛盾。
配置管理工具根據不同的平台推薦使用VSS和CVS，項目管理工具使用微軟公司的MSP。使用工具，可有效分解管理工作量，提升工作效率；有助於管理制度的真正落實，使體系更加固定化。 為了解決基礎薄弱的問題，需要在SPI前期為企業補基礎管理和基本軟體工程兩門課。
CMM的設計是以美國的軟體企業為研究對象，它假定企業在實施CMM前，已經具備了基本軟體工程和基本管理的能力，所以有「先管理、後工程」的觀點。就是先把項目管理到位，再實施軟體工程（即軟體工程到位）。
但是這個假定對於絕大部分的中國軟體企業是不成立的。
軟體企業需要補的基礎管理內容包括：基本時間管理、角色轉變、目標管理、溝通管理、基本人力資源管理等。基本軟體工程則包括基本的軟體工程生命周期、階段劃分、基本文檔編制等。 按照ISO9000的說法叫全員參與，分成三個層面就是：
一是高於項目管理的層面，稱為高層經理。他們提供資源和戰略兩方面的支持，所以高層經理應該對體系總體架構、體系實施必要性、可行性、障礙和風險、資源等負有責任。
二是項目管理層面，含項目經理和SPI人員。SPI人員作為制度化體系的執行者和推行者應該加強自身修養，要求別人的事，一定要自己能做到。而項目經理作為主要的一線實施人員，需要對整個體系的細節有深入了解和研究，應該把日常工作時間的30%～50%放在工程化管理相關事宜上，要貫徹公司的SPI整體制度，積極主動在項目組內進行推行。
三是項目組成員，包括開發和測試人員，要求團隊以紀律性要求自己，做好局部和整體、短期和長期的矛盾平衡。
特別要關注試點項目的PM（項目經理）選擇，選擇好的PM意味著SPI一半的成功。
需要說明的是，自底向上並不是絕對不做正式評估，如果需要，等到水到渠成再實施評估，不僅使得過程改進更實在，而且只需投入少量的資金就可獲得評估。
I. psp4000的軟體改進
軟體改動
一：屏幕鎖定 即：**指針時鍾**作畫面
二：固件中增加CPU**被屏蔽的內容**
三：系統改進 更省電 因採用新的CPU製程（45納米）技術（比原來的PSP1000，PSP2000，PSP3000省電一半）游戲時間更長 幾乎是以前掌機的一倍多
四：系統安全增加 無法破解 採用新的防破解技術！！無法安裝自製系統以及運行盜版游戲和自製軟體
五：可直接在系統下調整CPU頻率 兩個CPU可同時調整
六：兩個CPU同時為默認頻率環境下 運行游戲更快 更流暢
七：增加PS1模擬器插件 可直接運行PS2轉換後的游戲文件
八：PS3主機可與PSPgo聯機後 直接用PS3主機上的手柄控制PSPgo的游戲畫面 可當PS4的顯示屏
九：系統固件增加skype聊天軟體
十：可玩性更高 可與支持藍牙的手機互傳文件共享資源
十一：運算速度增加 提升性能50%左右
十二：增加無轉視頻播放（Real播放功能 該技術有可能不在PSP4000中增加 可能在PSP5000中增加）
十三：無線藍牙手柄技術 （需要購買PSP4000專用手柄）於2009年年底推出！
十四：新的PSP4000將增加專用的網路游戲！游戲內每個房間人數增至16人 增強互動性 增加的游戲有（怪物獵人PSP網路版 夢幻之星PSP網路版 真三國無雙PSP網路版 無雙大蛇PSP網路版 等
十五：網路電話功能
十六：增加語音PSP游戲！
十七：增加模式選項（PSP4000共有兩個選項 基本模式和游戲模式）
PSPgo待機時間大揭曉
PSPgo基本模式下（CPU頻率111 即兩個CPU同時運行下待機時間約8-10小時）
PSPgo游戲模式下（CPU頻率222 既兩個CPU同時運行下待機時間約6-8小時）
基本模式下 能運行PSP游戲 基本玩游戲 無法啟動錄制游戲功能 可運行音樂 視頻文件 等等基本功能
游戲模式下 能運行PSP的游戲錄制功能 並正常玩PSP游戲 能夠運行所有固件系統下的功能
J. 誰知道如何提高軟體質量
【摘要】 軟體質量是軟體產品的靈魂。本文全面介紹了質量的概念，提出了從流程、技術、組織管理、人員技能發展等多個角度提高軟體質量的重要性；並對目前國際上流行的 CMM 標准進行了介紹，提出了使用 PSP 和 TSP 來實現 CMM 的方法。本文最後還給出了中小型軟體公司在提高軟體質量方面的一個初步思路。【關鍵字】 質量管理，軟體開發過程模型，軟體分析和設計方法，軟體測試， CMM 如何提高軟體的質量已經不是一個純粹的技術問題，而是一個工程的問題。自從計算機誕生以來，相應的軟體開發就存在了。由於早期的計算機運行性能較低，軟體的可編程范圍也較狹窄，因此質量問題就沒有那麼突出。 50 年代後期到 60 年代，高級語言的相繼誕生並得到了廣泛的應用，隨之而來的是軟體規模也越來越龐大，越來越復雜。伴隨著軟體應用的越來越廣泛，軟體的質量問題就變得越來越突出。根據美國國家宇航局 NASA 的統計，在 80 年代初，軟體引起的故障與硬體引起的故障，其比率約為 1.1:1.0 ，到了 80 年代末，這一比率已達到 2.5:1.0 。因此如何提高軟體的質量成為軟體工程研究的一個重點。自從軟體危機產生以來，出現了很多提高產品質量的理論和方法，有的從技術角度出發，例如：面向對象技術的產生和推廣，第四代語言的誕生等等；有的從自動化工具入手，例如： CASE 工具、過程式控制制軟體、自動化管理平台等；有的從過程模型角度出發，例如：迭代模型、螺旋模型、 RUP 、 IPD 、凈室軟體工程等；也有從管理角度出發的，例如：團隊管理、績效管理、 PSP 、 TSP 等；也有從測試角度出發的，例如：加強全流程的測試等；一些相應的規范和標准也孕育而生，例如： ISO9000 系列、 CMM 、 QMS 等。然而每一種技術都不是絕對的，軟體質量的提高應該是一個綜合的因素，需要從每個方面進行改進，同時還需要兼顧成本和進度。一、什麼是質量？ 作為軟體產品的銷售人員，市場人員或維護人員經常會受到客戶這樣那樣的指責或抱怨，客戶說：你們產品的質量太差，不穩定等等。那麼什麼是質量呢？我們該如何來衡量質量呢？質量具有三個維度：" 符合目標。目標是客戶所定義的，符合目標即判斷我們是不是在做需要做的事情。" 符合需求。即產品是不是在做讓它做的事情。" 符合實際需求。實際的需求包括用戶明確說明的和隱含的需求。ISO 關於質量的定義表示如下：「 一個實體（產品或服務）的所有特性，基於這些特性可以滿足明顯的或隱含的需要。 」 注意，在這個定義中包含明顯的需求和隱含的需求。而往往我們會忽略隱含的需求。因此在控制一個產品的質量的過程中必須關注這些隱含的需求，並給予應有的驗證。 另一方面因為我們的產品是為客戶提供服務的，因此凡是不滿足客戶需求的，我們都認為是一個失效（ failure ）。所以我們的產品必須始終圍繞著客戶的需求進行開發和驗證。 這里我們談到客戶，其實在一個軟體的需求收集過程中需要關注客戶和用戶。而我們經常會忽略客戶與用戶之間的區別。那麼誰是客戶？誰是用戶呢？簡單的來說， 客戶是真正能夠決定是否購買你軟體的人，而用戶是實際使用軟體的人。了解了這個區別，對於你在分析需求的重要性的時候就可以進行參考。同時在產品質量驗證 的時候也可以做出不同的權衡。另一方面我們在考慮我們用戶需求的時候，往往只考慮了實際使用軟體的人員，而忽略了其它一些人員對軟體的要求或對軟體造成的 潛在競爭，這包括維護人員的要求、系統管理人員的要求、軟體上下遊人員的要求、先前版本的情況、市場上競爭對手的軟體情況等。 每個人提到質量的時候，經常會遇到下列矛盾，在這些矛盾中隱含著對質量的承諾【 5 】：" 質量需要一個承諾，尤其是高層管理者的承諾。但為了得到質量，高層管理者必須和其僱用的員工進行緊密合作；" 許多人相信沒有缺陷的產品和服務是不可能的。但是控制在一定級別的缺陷數是正常並可接受的；" 質量經常是和成本緊密聯系在一起，一個高質量的產品同時也意味著高投入。這是設計的質量和一致性質量的一個矛盾；" 一個高的質量要求需求規格說明書足夠詳細，以便產品可以根據這些規格說明書進行定量的分析。然而許多組織沒有能力或者不願意產生如此詳細程度的規格說明書；" 技術人員經常相信規范和標准會束縛他們的創造力，因此就不遵照標准做事。然而如果要得到高質量的產品，就必須遵循良好定義的標准和過程。二、流程對質量的貢獻 好了，既然已經了解了什麼是質量，那麼怎麼才能改進軟體產品的質量呢？從一個企業的長遠發展來看，首先應當從流程抓起，規范軟體產品的開發過程。這是一個 軟體企業從小作坊的生產方式向集成化、規范化的大公司邁進的必經之路，也是從根本上解決質量問題，提高工作效率的一個關鍵手段。 軟體產品的開發同其它產品（如汽車）的生產有著共同特性，即需要按一定的過程來進行生產。在工業界，流水線生產方式被證明是一種高效且能夠比較穩定地保證 產品質量的一種方式。通過這種方式，不同的人員被安排在流程的不同位置，最終為著一個目標共同努力，這樣可以防止人員工作間的內耗，極大的提高工作效率。 並且由於其過程來源於成功的實例，因此其最終的產品質量能夠滿足過程所設定的范圍要求。軟體工程在軟體的發展過程中吸取了這個經驗並把它應用到了軟體開發 中，這就形成了軟體工程過程，簡單的說就是開發流程。 無論做什麼事情，都有一個循序漸進的過程，從計劃到策略再到實現。軟體流程就是按照這種思維來定義開發過程，它根據不同的產品特點和以往的成功經驗，定義 了從需求到最終產品交付的一整套流程。流程告訴我們該怎麼一步一步去實現產品，可能會有那些風險，如何去避免風險等等。由於流程來源於成功的經驗，因此， 按照流程進行開發可以使得我們少走彎路，並有效的提高產品質量，提高用戶的滿意度。 目前流行的流程方法有很多種，不同的過程模型適合於不同類型的項目。瀑布模型是應用的最為廣泛的一種模型，也是最容易理解和掌握的模型，然而它的缺陷也是 顯而易見的。遺漏的需求或者不斷變更的需求會使得該模型無所適從。然而，對於那些容易理解但很復雜的項目，採用瀑布模型會是比較適合的，因為你可以按部就 班的去處理復雜的問題。在質量要求高於成本和進度要求的時候，該模型表現的尤其突出。螺旋模型是也是一個經典模型，它關注於發現和降低項目的風險【 8 】。螺旋型項目從小的規模開始，然後探測風險，制定風險控制計劃，接著確定下一步項目是否還要繼續，然後進行下一個螺旋的反復。該模型的最大優點就是隨著成本的增加，風險程度隨之降低。然而螺旋模型的缺點是比較復雜，且需要管理人員有責任心，專注以及有管理方面經驗。RUP （ Rational Unified Process ）是 Rational 公司提出的一套開發過程模型，它是一個面向對象軟體工程的通用業務流程【 9 】。它描述了一系列相關的軟體工程流程，它們具有相同的結構，即相同的流程構架。 RUP 為在開發組織中分配任務和職責提供了一種規范方法，其目標是確保在可預計的時間安排和預算內開發出滿足最終用戶需求的高品質的軟體。 RUP 具有兩個軸，一個是時間軸，這是動態的。另一個是工作流軸，這是靜態的。在時間軸上， RUP 劃分了四個階段：初始階段、細化階段、構造階段和發布階段。每個階段都使用了迭代的概念。在工作流軸上， RUP 設計了六個核心工作流程和三個核心支撐工作流程，核心工作流軸包括：業務建模工作流、需求工作流、分析設計工作流、實現工作流、測試工作流和發布工作流。核心支撐工作流包括：環境工作流、項目管理工作流和配置與變更管理工作流。具體可以參考圖 1 。 RUP 匯集現代軟體開發中多方面的最佳經驗，並為適應各種項目及組織的需要提供了靈活的形式。作為一個商業模型，它具有非常詳細的過程指導和模板。但是同樣由於該模型比較復雜，因此在模型的掌握上需要花費比較大的成本。尤其對項目管理者提出了比較高的要求。圖1 RUP 工作流程示意圖IPD （ Integrated Proct Development ）流程是由 IBM 提出來的一套集成產品開發流程，非常適合於復雜的大型開發項目，尤其涉及到軟硬體結合的項目。 IPD 從整個產品角度出發，流程綜合考慮了從系統工程、研發（硬體、軟體、結構工業設計、測試、資料開發等）、製造、財務到市場、采購、技術支援等所有流程。是 一個端到端的流程。在 IPD 流程中總共劃分了六個階段（概念階段、計劃階段、開發階段、驗證階段、發布階段和生命周期階段），四個個決策評審點（概念階段決策評審點、計劃階段決策評 審點、可獲得性決策評審點和生命周期終止決策評審點）以及六個技術評審點，具體可以參考圖 2 。 IPD 流程是一個階段性模型，具有瀑布模型的影子。該模型通過使用全面而又復雜的流程來把一個龐大而又復雜的系統進行分解並降低風險。一定程度上，該模型是通過 流程成本來提高整個產品的質量並獲得市場的佔有。由於該流程沒有定義如何進行流程回退的機制，因此對於需求經常變動的項目該流程就顯得不大適合了。並且對 於一些小的項目，也不是非常適合使用該流程。圖2 IPD 流程示意圖三、流程與技術 流程和成功不是等價的。沒有流程就成功是不可能得到保證，但有了流程並不意味著肯定能夠成功。這恐怕是很多迷信於流程的人所不能接受的。但這的確是個事實。記得有個做了將近 30 多年的需求分析專家說過：即使是一個已經達到 CMM4 級的公司，也完全有可能做不好需求分析。為什麼？技術，技術是成功的另外一個必要條件。就好比現在你要從上海到北京去，流程給你指出了最短的路徑，技術提供給你最快的交通工具。兩者結合就是完美。 對於軟體開發來說，要保證軟體的質量，需要掌握多方面的技術，包括分析技術、設計技術、編碼技術和測試技術等等。在國內有一個普遍的非正常現象，就是大家 覺得只有編程能力才是玩電腦的真正技能。就好像造一套房子，其它都不重要，只要磚瓦匠有高超的技能就行了。盡管這個比喻會打擊很多程序員的自尊心，但這的 確是一個事實。我們缺少系統級的工程師，在分析和設計方面的工作做得很不扎實。需求是一個項目的靈魂。模稜兩可的需求帶來不可避免的後果便是返工 —— 重做一些你認為已做好的事情。返工會耗費開發總費用的 4 0 % ，而 7 0 % ～ 8 5 % 的重做是由於需求方面的錯誤所導致的（ l e ff i n g w e l l1 9 9 7 ）【 10 】。想像一下如果你能減少一半的返工會是怎樣的情況？你能更快地開發出產品，在同樣的時間內開發更多、更好的產品，甚至能偶爾回家休息休息。在《軟體需求》一書中關於如何進行需求分析給出了比較詳細的介紹【 7 】， RUP 中關於需求的指導也是很實用的。 設計是最能體現一個工程師能力和水平的環節。一個好的設計基本上決定了產品的最終質量。設計是把需求轉換成系統的一個關鍵步驟，它需要從自然語言描述的需求中尋找出設計的基礎單元，構建出整個系統的構架。在 RUP 中關於系統構架師和設計師的定位是相當高的。關於設計方面的技能涉及面是很廣的，包括傳統的結構化設計到面向對象設計。設計人員需要掌握一定的建模技術。 UML 是國際上比較流行的一種建模語言【 11 】。在嵌入式方面， SDL 也是一種非常好的選擇。《設計模式》是在設計思想方面總結的非常出色的一本書【 6 】，作為一名設計人員（尤其是面向對象設計人員）必須要好好研究一下。但是對這些模式的應用應當講究一種自然的應用，千萬不要因為模式而去設計模式，否則會適得其反。 現在的程序員熱中於掌握多種編程語言，或者講究語言的過分技巧化，而往往忽略了編程語言的規范化。不規范的語言應用給程序的可理解性、可維護性以及可測試 性帶來了大的傷害，進而損害了產品的質量。某公司曾對中國程序員和印度程序員做過一個測驗，這個測驗要求參加者對一組數進行排序。測試結果發現，印度程序 員設計的程序使用的演算法並不是最優，但卻是最不容易出錯的，並且幾個程序員寫出來的代碼如出一轍。而幾個中國程序員寫出的代碼，有的非常漂亮，很精練，效 率很高；有的卻很冗雜，還有錯誤。如果大家是在做研究性的項目或純粹興趣性的項目，那麼充分發揮自己的編程天才也無可厚非。然而，對於一個軟體公司，產品 最終是要交給用戶的，需要遵循的是一個軟體產品的開發工程。因此這類軟體的開發需要遵循一定的編程規范，畢竟開發的軟體不是自己用，還需要和別人的集成， 還需要給以後版本重用和維護。 測試的技術將在第五節進行闡述。總之流程很關鍵，技術也很重要，我的觀點是：魚和熊掌，兩者都不能放。