90-90法則

90-90法則

90-90法則(ninety-ninety rule,九九定律,99定律)是計算機編程和軟體工程領域的一個有名的法則,是指開發軟體時前90%的代碼要花費90%的開發時間,剩餘的10%的代碼要再花費90%的開發時間。合計180%的時間總量用看似荒誕的形式指出了軟體開發項目里一個臭名昭著的傾向-完成時間常常嚴重超出預期時間表。這一格言體現出了軟體工程的對編程項目的簡單與困難部分的時間分配太過粗糙的問題,也揭示了許多項目拖延的原因(即對困難部分沒有足夠的估計)。換句話說,完成一個項目要花比預期的更多的時間和代碼。

基本介紹

  • 中文名:90-90法則
  • 外文名:ninety-ninety rule
  • 領域:軟體工程
  • 影響:軟體開發時間遠遠超出預期
  • 原因:編程項目分配不合理
  • 提出者:Tom Cargill
簡介,軟體項目管理,風險策劃,有關因素,

簡介

90-90法則簡單來說是指軟體項目開發利用的時間是計畫時間180%,即最後10%工程量所花的時間與90%工程量所花的時間相同,是軟體項目中,風險策劃的主要研究內容。造成這一現象的原因是進行軟體架構設計和軟體項目進度管理時,對軟體開發過程中的可能遇到的困難認識不足。這一法則被認為是貝爾實驗室的Tom Cargill所提出,後來因為Jon Bentley在《ACM通訊》上的“編程珠璣”(Programming Pearls)專欄的“可靠性法則”(Rule of Credibility)一文而流行。這句格言也收錄在Jon Bentley後來出版的“編程珠璣II”(More Programming Pearls)一書中。

軟體項目管理

軟體項目管理是為了使軟體開發項目能夠在預定的進度、成本、質量的目標基礎上完成軟體項目開發的工作。軟體項目管理是對軟體產品、開發人員、項目開發過程進行必要的分析和規範的管理的工程活動。
軟體開發項目管理的基本目的是,讓軟體項目在整個軟體生命周期中(從需求分析、概要設計、詳細設計、編碼調試和測試驗收、維護的所有過程中)都能在項目管理者的可監控之下進行,以滿足預訂的成本、按照預訂的日程且保證質量的前提下,生產出滿足客戶需求的軟體並交付給客戶。而研究軟體項目管理的目的,是為了通過從已經成功或失敗的軟體開發項目的案例中,總結出軟體開發的通用原則和方法,用於以後的項目的管理工作。同時儘量避免前人產生的失誤,從而降低在新項目中問題出現的次數。軟體具有一定的特殊性,和其他工業產品不同,它是一種高邏輯的智力性產品,他是純知識產品,軟體項目開發的進度和質量不容易被估量和估計,生產效率也很難被預測和保證,再加上軟體開發系統的複雜性也增加了對軟體系統難以預見和難以控制的風險。軟體開發的過程也是需要進行複雜的邏輯思維,和以往的傳統工業產品相比較,軟體的設計過程是貫穿於全部的軟體開發過程,軟體開發主要是需要使用較高素質的人力資源,在物質資源的投入的需求較少;軟體開發的最終成果物一般僅僅是程式代碼和技術性檔案及說明和使用文檔。軟體項目管理的對象是成本、進度、質量和風險,軟體開發團隊成員在項目開發過程中的大力配合是軟體項目管理實施的基礎和保障。
軟體項目管理的主要內容包括:人力資源的組織管理、軟體規模質量進度上的度量、項目風險管理、項目計畫與策劃、質量保證體系、過程能力評估和配置管理等方面。以上若干方面需要互相協調,貫穿整個項目始終。人員組織管理工作主要是需要考慮人員的構成和人員具備的知識水平;軟體度量,主要是定量評估軟體的規模、軟體生產效率、項目進度和軟體質量是否達到預期的指標;風險管理主要是預測可能在軟體開發過程中出現潛在的風險,並積極採取有效策略來預防風險的發生,和在風險發生時採用有效的降低風險影響範圍的措施;過程能力評估主要是測試軟體的開發過程的能力;配置管理主要是分配和管理人力資源、物力和財力資源的工作。

風險策劃

對於任何項目,風險管理都是一項重點,風險管理的好壞可能會直接影響項目是否可以按期或者保證質量的完成。因此項目經理必須通過學習項目管理知識,從而有項目風險管理的必備知識的儲備,加強對項目計畫中的風險的識別和跟蹤,提高項目的管理意識。總結本行業項目中常見的風險及並記錄對策作為風險管理計畫中必要的內容,之後組織人員評審和評估相應對策的有效性和可行性。項目負責人及項目干係人共同完成風險的識別活動。對已經識別出來的風險,進行分析:
  • 確定風險的類型。
  • 分析風險的危險程度。
  • 分析風險所發生的機率。
  • 分析風險的生存期限或者結束條件等信息。
定風險的策略,根據風險不同,制定不同的風險環節策略和風險發生時的緊急措施,並確定相關措施的責任人。

有關因素

需求分析:主要對用戶提出的需求進行分析的工作。是對用戶所要求的業務活動進行分析,確定目標,包括系統的目的、工作的範圍、定義以及滿足的功能,明確在用戶的業務中,軟體系統應該完成哪些工作。只有在明確了客戶需求之後,才能知道要“做什麼”,才能夠分析和建立系統的解決方法,從而開展後續的工作,因此需求分析是軟體工程活動中的最為關鍵的過程活動。
系統設計:參照需求理解的成果物,對整體的軟體系統進行架構設計的工作,將軟體系統劃分為若干模組,並規定個模組的職責。軟體結構設計的目的是將一個複雜系統,按照功能進行模組的劃分。同時建立出模組的層次結構和模組之間的調用關係、確定模組間的數據和事件的接口,UI及人機界面等內容。數據結構設計的主要目的,是數據特徵的描述、確定數據的結構特性、以及資料庫的設計。同時製作給模組之間主要功能的流程圖。
詳細設計:參照系統設計的成果物,設計各子模組的內部結構圖,各模組的接口,模組內部的功能流程圖等。為各模組確定算法,選擇其適當的工具用以表達其算法的過程,並且寫出模組的過程描述;明確每個子模組所用到的數據結構類型;明確每個模組接口的細節,其中包括對系統以外接口和對用戶界面,對系統內部與其它子模組的接口,以及模組的輸入和輸出數據,以及模組內部數據的全部細節。要為每一個模組設計定義出測試用例,用以在編碼的結束對模組代碼進行預定的測試。

相關詞條

熱門詞條

聯絡我們