軟件項目的目標
在討論這些最佳實踐之前，先明確一下軟件項目的目標，因為所有的最佳實踐都是為實現項目目標服務的。Alistair Cockburn在他的著作《敏捷軟件開發》中指出，軟件項目的目標有兩個，取得當前項目的成功并進行積累，為后續的項目做準備。
關于第一個目標，一個比較麻煩的事情就是如何定義成功。一般來說，大家認為在預算范圍和進度計劃之內交付客戶想要的產品，項目就算是成功的。但這樣的理解似乎過于初級。Dewys Lasdon曾指出，&ldquo我們的工作不是用限定的費用及時地給客戶他想要的東西，而是給他從未夢想過的東西當他得到的時候，他意識到這就是他一直想要的東西。&rdquo如果你結合iPod取得的成功來看，就能很好地理解這段話的含義了。
關于第二個目標，主要有兩層意思。第一層意思是&ldquo鍛煉隊伍&rdquo。在項目中，團隊共同工作一段時間，進行了許多&ldquo戰術配合&rdquo方面的練習，大家相互之間更有默契。對于個人來說，通過具體的開發實踐，學習了不少新知識，也積累了經驗。
第二層意思是為后續項目提供積累。后續項目可能是運維項目，也可能是產品的下一個版本，或其他項目。不少項目開發工作對于后續項目有重要意義，如項目文檔和回歸測試套件等。如果你曾接手過別人的項目，或者只是花時間讀過別人的程序，就一定會對此深有感觸。
順便提一下，項目的第二個目標不一定是次要目標。對于某些領航項目或概念驗證項目來說，為后續項目提供經驗積累就是項目的首要目標，也是項目成功的衡量標準之一。
RUP
根據IBM的官方說法，&ldquoRational Unified Process是一個靈活的軟件開發流程平臺。借助它可配置的構架，RUP 使你能夠只選擇和部署項目的每個階段需要的流程構件。RUP 平臺以業界公認的軟件工程最佳經驗為核心，它包含配置 RUP 以滿足項目特定需求的工具。從這種意義上說，RUP 是一個軟件開發方法框架，以及一個公認的、靈活的、實用的流程平臺，用于成功的軟件項目。&rdquo RUP提出了六項最佳實踐:
1. 迭代的開發軟件
2. 需求管理
3. 使用基于構件的體系結構
4. 可視化軟件建模
5. 驗證軟件質量
6. 控制軟件變更
讓我們來看看其中的需求管理。一項調查(James Martin An Information Systems Manifesto，Prentice Hall，1984)表明56%的缺陷其實是在軟件需求階段被引入的。而這其中的50%是由于需求文檔編寫有問題、不明確、不清晰、不正確導致的。剩下的50%是由于需求的遺漏導致的。更重要的是，許多需求缺陷直到很晚才被發現。而缺陷發現得越晚，修復缺陷所需的代價就越大。所以在傳統軟件工程方法中，非常重視需求工作，甚至稱這部分工作為需求工程。
需求工程的主要出發點是減少需求中的缺陷，從而降低項目風險。Joel Spolsky 指出:“首先，沒有編寫規格說明是軟件項目中你所承擔的一個最大的、不必要的風險�！碧貏e是在外包項目中，絕大多數客戶都不會同意沒有需求規格說明書的開發方式，因為這樣做風險太大，實在不值得冒這個險。
需求工程的另一項重要使命是發現機會，即發現創新的產品，為用戶提供更多價值的機會。如果你草率對待需求工作，將喪失這種機會。例如，在我們進行業務流程分析時，應該適當關注企業流程再造，業務管理創新，實現更多客戶價值的機會。只有這樣，才能可能做出Dewys Lasdon所說的“客戶從未夢想過的東西”。
需求工程中的一個重要方面是管理需求的可追蹤性，即從項目的總體目標追蹤到業務用例，再追蹤到實現用例和具體需求，最后追蹤到實現和測試的能力。如果忽視了這個方面，項目的開發可能會偏離方向。
我們在編寫需求時，常常會用到一些文檔模板，如需求規格說明書模板和用例模板。某些模板非常全面、細致，以至于某些部分我們初看上去甚至覺得可以忽略掉。但是當你打算忽略掉模板中的這些部分時，千萬要小心，因為模板的主要作用之一就是降低遺漏需求的風險。
有一次一名項目經理打算在開發團隊中引入用例模板，查找了一些資料之后，寫了一個草稿讓我復查一下。我發現他的模板中沒有用例的使用頻度，問他時他說，覺得沒有太大作用就裁掉了。于是我告訴他，用例使用的頻度對系統的設計和實現有很大的影響，這屬于系統的非功能需求，不能省略。
文章來源于領測軟件測試網 http://www.kjueaiud.com/