軟體開發基本原則（一）—— 策略和因素

前 言

 

　　前段時間一直在寫技術方面的文章，現在想轉轉口味，從軟體開發過程和專案管理的角度來談論軟體開發。本座也知道，從這兩個角度來談論軟體開發對談論者來說是非常冒險的一件事情，它不像技術，對就對錯就錯，有一個客觀的評判標準，別人想噴你也得自己先好好研究等拿到了足夠的論據才能噴，但開發過程和專案管理就不同了，別人僅憑一點點所謂的管理經驗甚至是主觀推斷就能噴得你體無完膚，搖搖欲墜 ~ 因為沒有什麼所謂的事實標準與放之四海皆有效軟體開發過程和專案管理方法。保守估計，100個人中至少有150種想法。本座也深知其中的兇險，因此避重就輕，從基本原理談起，宏觀的角度闡述相關問題，盡量減少中彈的機會。歡迎大家暢所欲言 ^_*

 

　　註：本文大量圖片和素材來自《Rapid Development》(Steve McConnell 1996)

 

1 概 述

 

　　時間 -- 成本 -- 品質（或特性）是評價軟體項目成敗的三個關鍵計量，這三個指標之間相互影響和制約，形成了所謂的“專案管理三角形”。要提高品質或增加特性意味著成本和時間的增加，或兩者都增加；要在時間不變的前提下縮減開發成本或成本不變的前提下縮減時間則意味著品質的下降或特性的削減。

 

 圖 1-1 專案管理三角形

 

　　上述分析其實只是理論上的“理想平衡”狀態。現實工作中往往出現的情形是：要麼時間超過計劃，要麼成本超過預算，要麼品質達不到要求，要麼三個指標都達不到預期。

 

　　典型例子：

　　由於客戶的壓力需要盡量縮減開發時間，由於企業間的競爭和盈利壓力需要盡量節約成本，因此需要一個人做兩個人的工作，一個月做兩個月的工作，同時壓縮需求分析、設計、測試、評審和項目會議等活動。可想而知，即使軟體的構建階段能夠按時完成，但做出的軟體品質是難以保證的。更糟糕的還在後面：由於品質的低劣，構建階段結束後對系統進行整合測試時，很多問題就會暴露出來：對某些需求的理解有誤差，導致這部分功能要重新分析、設計、編碼和測試；架構設計缺乏整體思維導致系統不同模組各自為政，產生大量重複的難以維護的代碼；編碼太倉促導致一大堆的Bug；溝通不暢順導致模組介面不相容……從而項目被帶入了修改無限迴圈地帶，即使勉強上線發布，修改還是一直持續，直至最後，沒有人再敢接近這套代碼，對這個項目談虎色變。

 

　　軟體開發項目有其自身規律和原則，只有遵守其原則並付諸相應的實踐才可能使項目健康穩定地前進。本文講述的是軟體開發的基本原則，它是通用的，幾乎適用於所有的軟體開發項目。不同項目可以根據自身特點在原則的指導下定義相應的項目開發實踐。

 

2 策略和因素

 

2.1 總體策略

　　要避免混亂低效的開發，就要求每個人能夠放棄他們自己的一些壞習慣，通過採取以下四種策略實現快速開發：

　　1、 避免典型錯誤

　　2、 打好開發基礎

　　3、 管理風險，避免災難發生

　　4、 採用面向進度的實踐

  

 圖 2.1-1 快速開發的四跟支柱

 

　　典型錯誤：是指一些經常被許多人使用的無效的開發實踐，如：不現實的預期，缺乏計劃，功能蔓延和銀彈綜合症等。將在第3章詳細講解。 

　　開發基礎：是指項目開發過程中管理、技術、品質保證等方面行為和活動，如：計劃編製，需求管理和技術回顧等。將在第4章詳細講解。

　　風險管理：是指對有可能影響項目的風險進行評估和控制。將在第5章討論進度計劃相關的風險。 

　　面向進度的實踐有以下三類：

• • 面向速度的實踐：可以提升開發速度，協助你更快的交付軟體
  • 面向進度風險的實踐：可以降低計劃風險，協助你的項目平穩推進
  • 面向可視化的實踐：可以提高進程的可視化程度，協助你掌握項目動態

 

圖 2.1-2 面向進度的實踐

 

       圖2.1-1所示的前三根柱子為可能的最佳進度提供了最重要的支撐，雖然可能不是最理想的，但卻是最需要的。也就是說，即使不藉助於面向進度的實踐方法，也可能實現較最佳化的項目進度；但是，如果僅僅依賴面向進度的實踐卻不可以支撐可能的最佳進度計劃。

 

圖 2.1-3 僅僅依賴面向進度的實踐不足以支撐最佳進度計劃

 

2.2 軟體開發的四維

　　每個軟體項目都有四個重要的維：

• 人員：完成任務要麼快，要麼慢
• 過程：最佳化人員的工作效率，或者浪費人員的時間
• 產品：以自我完善的形式定義，或者阻礙人員達到最好效果的形式定義
• 技術：促進或者阻礙開發的實現

  

圖 2.2-1 開發速度的四維

 

2.2.1 人員

 

　　研究資料： 

 

       人件極大地影響著生產效率，任何關注提高生產效率的組織首先必須有一套良好的人員激勵、團隊合作、員工選擇及培訓機制。

 

       發揮人員最大潛能，縮短項目周期的方法：

 

1、 項目成員的選擇

五個原則：

• 用更少更好的人
• 使任務與人員的技能和動機相匹配
• 協助人員自我實現，而不是強制地把他推到他最有經驗或最需要他的崗位上
• 人員選擇應強調人員之間的互補與協調性
• 儘快排除或替換不稱職的人員

 

　　2、 團隊組織圖

　　人員的組織方式對人員的工作效率有很大影響，調整項目團隊以使之與項目規模、產品特點以及進度目標相匹配。特定的軟體項目也可以從適宜的專門組織中受益。

 

　　3、 人員激勵

　　人員激勵能激發人的動力，從而付出額外的努力工作；它適用於不同組織、不同項目和不同人員。人員激勵是達成快速開發的最具潛力方法。

 

2.2.2 過程

 

　　研究資料：

　　Hughes Aircraft、Lockheed、Motorola、NASA、Raytheon和Xerox等組織通過對開發過程的改進將產品上市時間縮短了一半，降低成本、減少錯誤為原來的1/3~1/10。

 

　　過程是指軟體開發生命週期中定義的一系列工作流程和活動的集合。可以概括為以下三類：

• 基本過程：包括擷取過程、供應過程、開發過程、運作過程、維護過程和管理過程
• 支援過程：包括文檔過程、組態管理過程、品質保證過程、驗證過程、確認過程、聯合評審過程、審計過程以及問題解決過程
• 組織過程：包括基礎設施過程、改進過程以及培訓過程

 

　　忽略過程容易造成工作效率低下，工作目的交叉重複，產品品質難以保證等問題；另一方面，如果過程過於嚴格、過於官僚同樣會挫傷人員的積極性，或者由於執行過程的成本過高而影響實際的工作效率。

 

　　組織可以對現有的過程進行裁剪和調整，制定出適合特定項目的過程；或者可以為項目從頭開始定義過程。無論是裁剪過程或是定義過程，應該把關注點放在以下幾個方面：

 

　　1、 避免返工

　　軟體項目節省時間一個最直接的方式就是確定過程，避免重複工作。如果在項目最後階段改變需求，就可能不得不重新設計、編碼和測試；如果直到系統測試階段才發現設計有問題，就可能不得不扔掉已經細化的設計和編碼。

 

　　2、 品質保證

　　品質保證有兩個目的：

• 確保交付的產品能夠達到可接受的品質水平
• 在各階段以最少的時間和成本代價查出錯誤

 

　　應儘早在錯誤發生的時候就查出來，錯誤在產品中停留的時間越長，清楚錯誤所花費的時間和成本就越多。品質保證是任何開發過程中必不可少的部分。

 

　　3、 開發基礎

　　一系列的軟體工程實踐活動形成了開發基礎，如：分析、設計、構建、整合和測試等。在過程中對開發基礎加以關注，並定義良好的工作規範和任務集合能防止項目失控。

 

　　4、 風險管理

　　與進度相關的風險管理是開發過程必要的組成部分。風險管理雖然不能直接提高開發速度，但它是避免項目災難的有效實踐。

 

　　5、 資源目標 

　　資源套件括人力資源、環境資源和軟硬體資源等。最佳化資源的調配有助於提高生產率。

 

　　6、 生命週期計劃

　　生命週期計劃是基本的管理計劃，有助於確定軟體項目要進行的活動集合和資源分派。每種周期模型都有其適用範圍和缺點，為項目選擇適當的生命週期模型能有效提高工作效率或降低項目風險。

  

圖 2.2.2-1 純瀑布模型

 

圖 2.2.2-2 瀑布模型的另一種形式——鮭魚生命期模型

  

圖 2.2.2-3 編碼修正模型（一種不規範的模型）

 

 圖 2.2.2-4 螺旋模型

 

 圖 2.2.2-5 生魚片模型

 

圖 2.2.2-6 包含子項目的瀑布模型

  

圖 2.2.2-7 能夠降低風險的瀑布模型（對需求分析和架構設計階段採用螺旋模型）

  

圖 2.2.2-8 漸進原型模型

 

 

圖 2.2.2-9 階段交付模型

 

圖 2.2.2-10 面向進度模型

  

圖 2.2.2-11 漸進交付模型

 

圖 2.2.2-12 面向開發工具的設計模型

 

 

　　7、 面向客戶開發

　　誰是客戶？

　　對客戶的理解取決於場合，可能是項目委託人，終端使用者，市場人員或者老闆。

 

　　現代軟體開發非常關注客戶的需求與期望，開發出合符產品規格的軟體只是完成了一半工作，另一半是協助客戶配置出產品能夠實現的功能，而實現這些功能所花費的時間通常遠遠多於確定紙面上的產品規格所需要的時間。

　　將自己站在客戶的角度考慮問題是避免大量返工的最好方法。同時應該建立有效客戶溝通渠道，合理控制客戶的期望值。

 

2.2.3 產品

 

　　在軟體開發的四維中，最切實的維是產品維。對產品規模和產品特性的關注，意味著巨大的縮短計划進度的機會。削減了產品功能通常就可以縮短產品開發週期。

 

　　1、 產品規模　　

　　產品規模是對開發進度影響最大的一個因素。構建軟體所需的工作量的增長比產品規模的增長要快得多，並且增長是不成比例的，所以產品規模的縮小將大大提高開發速度。將中等規模的軟體削減一半通常可以使工作負載削減2/3。

 

　　2、 產品特性

　　產品的一些非功能性需求或額外關注點會影響設計的複雜度和構建的工作量，如對效能、穩定性、可維護性和可擴充性等要求很高的產品比沒有這些特性要求的產品需要更長的開發週期。

 

2.2.4 技術

 

　　從使用低效的工具轉為使用高效的工具是提高開發速度的快捷方法。選擇有效工具並管理好由此帶來的風險也是提高開發速度的方法。

 

　　敬請期待：軟體開發基本原則（二）—— 典型錯誤

CodeProject