統(tǒng)一過程最佳實踐細化階段

　　內(nèi)容簡介目錄本書重點介紹了與統(tǒng)一過程的細化階段相關(guān)的最佳實踐。通過對諸如代碼走查、配置管理、變更控制和軟件組織架構(gòu)建模等最佳實踐的介紹說明了實現(xiàn)軟件過程的細節(jié)。本書可以作為軟件項目管理人員、軟件開發(fā)工程師、過程工程師、系統(tǒng)工程師等專業(yè)人員的指導用書，也可作為高等院校計算機及相關(guān)專業(yè)學生的參考書。前言 Software Development雜志（www. sdmagazine. com）以及它的前身Computer Language曾經(jīng)發(fā)表過大量關(guān)于如何成功開發(fā)軟件的文章. 曾經(jīng)以及還在為該雜志寫作的很多作者都是令人印象深刻的：Steve McConnell. Ed Yourdon. Larry Constantine. Steve McCarthy. Clemens Szypers-ki. Peter Coad以及KarlWiegers等. 這些信息產(chǎn)業(yè)的著名專家已經(jīng)通過這本令人尊敬的雜志同我們分享了他們的智慧成果. 后來， 更多的組織開始逐步將更多的精力投入到提高軟件過程上. 這部分是因為千年蟲（Y2K）的災難， 大約80％～90％的大規(guī)模軟件項目的失敗， 和與日俱增的對于遵循成熟軟件過程是決定一個軟件項目成功與否的關(guān)鍵的認識. 從20世紀90年代中期以來， Rational公司就開始收購和合并別的軟件公司， 這樣做的結(jié)果是， 將這些工具所支持的過程合并到單個開發(fā)過程中， 即所謂的統(tǒng)一過程. 是不是有可能將整個軟件過程自動化呢？即使可以將其完全自動化， Rational有一個完整的工具集嗎？我不太確定. 幸運的是， 還有其他的人也在致力于定義軟件過程：OPEN聯(lián)盟的OPEN過程就是其中之一， 我自己的面向?qū)ο筌浖^程（OOSP）的過程模式也是一個：所以我們對于怎么去做這樣的工作還是有些其他的觀點. 這些其他的觀點能夠用于驅(qū)動一個更加健壯的統(tǒng)一過程， 并且為準確反映你的組織的真實需求的統(tǒng)一過程產(chǎn)生一個增強的生命周期. 我相信在Software Development多年積累起來的智慧成果能夠用來充實統(tǒng)一過程， 并且能夠統(tǒng)一業(yè)界的最佳實踐. 正因為如此， 我們出版了這套叢書. 遵循一個經(jīng)過證實的. 成熟的過程是軟件專家成功的關(guān)鍵. 為什么軟件過程這么重要？我們后面就會討論這個問題. 假如你想建造一座房子， 并且讓兩個建筑商來競標. 第一個告訴你通過使用新的建造技術(shù)， 他能在兩周內(nèi)為你建造一座房子， 如果他第二天就開始建造的話， 這座房子將僅僅花費100000美元. 這個建筑商有一些頂級的木匠和管道工， 并且在過去已經(jīng)使用這種技術(shù)建造過一個花園洋房， 并且他們也愿意日夜加班工作保證按時完成. 第二個建筑商告訴你他需要跟你討論你希望建成什么樣的房子， 當他一旦清楚你的需求后， 將在一周內(nèi)將你的需求做出一個草圖， 然后你可以審查并且反饋給她你的意見. 這個初始階段將耗費你10000美元， 而一旦你決定了想要建造的樣式后， 他會把詳細計劃和剩余工作的費用安排綜合起來. 你對哪個建筑商更加放心呢？想立刻開始建造的那個還是想先了解你對建造樣式需求， 做出模型， 做出計劃然后再建造的那個呢？顯然， 第二個建筑商有更大的機會做出滿足你實際需求的房子. 現(xiàn)在設(shè)想你正在構(gòu)建軟件：這是一項比建房子復雜程度高出幾個數(shù)量級， 并且常常是更加昂貴的工作：并且再一次假設(shè)你有兩個承包商， 而且他們使用上面兩種方式. 你對哪個更加放心呢？我希望答案仍然是第二個：一個明智的過程. 不幸的是， 實踐證明絕大多數(shù)的時間內(nèi)， 組織往往會選擇第一個承包商所使用的方法. 當然， 實踐也說明我們有大約85％的失敗率， 你認為兩種現(xiàn)象有關(guān)聯(lián)嗎？我想是. 細化階段 細化階段是4個階段的第2個. 這4個階段包括：初始階段. 細化階段. 構(gòu)造階段. 交付和產(chǎn)品化階段. 在細化階段， 軟件的發(fā)布貫穿了它的整個生命周期. 這個階段有幾個目標： ·為系統(tǒng)產(chǎn)生一個經(jīng)過證實的. 架構(gòu)的基準. ·讓需求模型發(fā)展到"80％的完成點". ·為構(gòu)造階段開發(fā)一個粗粒度的項目計劃. ·確保關(guān)鍵的工具. 過程. 標準和指南已經(jīng)為構(gòu)造階段準備好. ·了解并消除項目中風險級別高的問題. 本書介紹了一組由業(yè)界專家所撰寫的文章， 這些文章講述了最佳實踐的前沿知識. 本書的一個目標， 并且也是這套書的總的目標， 是為統(tǒng)一過程技術(shù)提供可選的. 經(jīng)過證實的方法. 本書的另一個目標則是填補統(tǒng)一過程的漏洞：坦白地說， 沒有任何過程可以真正稱為"完整"的. 統(tǒng)一過程是開發(fā)過程而不是軟件過程， 因此， 正因為它所選擇的范圍， 它必然會略過一些軟件專業(yè)方面的重要概念. 但幸運的是， Software Development中的作者們都使用了更為廣闊的視角來看待過程. 關(guān)于這套書 本套書由四本書組成：分別為初始階段. 細化階段. 構(gòu)造階段以及移交階段和產(chǎn)品化階段. 每本書都自成體系， 但通過整個系列才能夠完整了解軟件過程. 由于每本書中的文章都不重復， 你會發(fā)現(xiàn)每一本書都很有價值. 有時候， 可能其中一本書中講述的比較薄弱的過程工作流在其他幾本書中講述得更為詳盡. 例如， 關(guān)于初始階段的書中包括了大量項目計劃和評估的內(nèi)容：這也是開始一個項目時最關(guān)鍵的內(nèi)容：而在其他幾本書中這方面的討論就比較少. 另外， 在著手編著這套系列叢書時， 我發(fā)現(xiàn)要比最初想像得難許多. 我所碰到的問題在于， 好的資料很多， 但本系列叢書卻只有有限的容量. 所以大家可以發(fā)現(xiàn)本系列書中的文章都是精華中的精華. 關(guān)于我本人 作為Computer Language以及后來的Software Development雜志多年來忠實的讀者， 我從1995年開始為它撰寫文章， 并在1997年成為對象技術(shù)專欄的作家. 我在20世紀80年代初期開始軟件開發(fā)的工作， 曾經(jīng)使用Fortran以及Basic語言來編寫代碼， 在80年代中期使用過Turing. C. Prolog以及Lisp. 在80年代后期， 我意識到有比編程生命周期更為長久的工作， 所以我開始重新學習用戶界面設(shè)計. 數(shù)據(jù)建模. 過程建模以及測試的技術(shù)， 那時我用COBOL和第四代語言在IBM主機上編程. 當我從結(jié)構(gòu)撾程技術(shù)中醒悟過來后， 在1990年我發(fā)現(xiàn)了對象， 并很快地一頭扎入Smalltalk開發(fā)中， 接著是C++開發(fā)， 最后又重新回到Smalltalk. 在幾個機構(gòu)中擔任指導者以及架構(gòu)師后， 我決定將這些經(jīng)歷以及我所獲取的技術(shù)結(jié)合， 并在多倫多大學獲得了一份助教的工作， 在90年代中期開始從事職業(yè)培訓工作. 不久之后， 我就意識到下面兩件事情， 首先， 盡管我很喜歡教授培訓課程（我到今天仍不曾間斷）， 但我并不希望做一個全職授課者. 其次， 更重要的是， 我學習到如何使用簡單易懂的方式來交流復雜的概念， 例如怎樣開發(fā)面向?qū)ο筌浖? 基于這樣的經(jīng)驗， 我最初的兩本書誕生了：《The Obiect Primer》（Cambridge University Press， 1995）以及《Building Obiect Applications That Work》（Cambridge University Press， 1997／1998）：這兩本書從開發(fā)者的角度講述了對象技術(shù)的基礎(chǔ)知識. 緊接著， 我在《Process Pat-terns》（Cambridge University Press， 1998）一書中繼續(xù)講述了面向?qū)ο筌浖^程， 并在另一本書《More Process Patterns》（Cambridge University Press， 1999）中提供給讀者我在加拿大某個一流的對象技術(shù)咨詢公司所獲得的寶貴經(jīng)驗. 從那時開始， 我?guī)椭^多家機構(gòu)（無論大小， 成立時間長短， 所屬行業(yè)）來提高他們的內(nèi)部軟件過程. 我近期的著作包括本系列叢書以及另一本書：《The Elements of Java Style》（Cambridge University Press， 2000）. 我想， 我已經(jīng)發(fā)現(xiàn)了屬于我自己的體系結(jié)構(gòu).序言 信息技術(shù)行業(yè)最不為人知的事就是那些大型的. 關(guān)鍵性的項目有80％～90％最終都遭遇失敗. 對于從事軟件開發(fā)工作超過15年， 并在3年前剛剛成為編輯的我來說， 對此深有體會. 當我剛剛開始成為Software Development雜志的技術(shù)編輯時， Scott Ambler開始在"Thinking Ob-jectively"專欄中發(fā)表文章. 他使用日常用語來寫作， 這使得普通的開發(fā)者都能夠閱讀. 在諸如過程模式. 有效使用UML以及將對象映射到關(guān)系型數(shù)據(jù)庫中等前沿技術(shù)領(lǐng)域， Scott堪稱專家. 現(xiàn)在Scott開始將他的熱情和興趣投入到如何將大多數(shù)軟件項目從高失敗率的深淵中解救出來. 軟件過程涉及如何標準化開發(fā)團隊的工作并促進在業(yè)界長期共識的最佳實踐， 例如代碼走查. 配置管理. 變更控制以及架構(gòu)建模. 擁有過程模式開發(fā)背景的Scott， 正處于一個對當前的面向?qū)ο蟮能浖^程（例如Rational統(tǒng)一過程， 即RUP. OPEN聯(lián)盟所提供的OPEN過程以及面向?qū)ο筌浖^程， 即OOSP）可以提供一致而有重點的評價的理想位置. 盡管OOSP（詳見Scott的（ProcessPatterns》和《MoreProcessPatterns》）為過程模式提供了更好的內(nèi)在支持， 但Scott認識到：盡管面臨挑戰(zhàn)， 統(tǒng)一過程是市場領(lǐng)導者， 而且還將繼續(xù)下去. 正如Scott所說的（"增強統(tǒng)一過程"， Software Development， 1999年10月）， "統(tǒng)一過程不是完美的：沒有任何軟件過程是完美的：但是， 如果我們想要在軟件領(lǐng)域成功， 它是我們需要投入工作的一個領(lǐng)域. "這個系列書籍從OPEN過程和OOSP里抽取了資料來充實目前還單薄的統(tǒng)一過程. 在我看來， 一個充實的統(tǒng)一過程是處理這一尷尬問題的最好的方式之一， 同時Scott就是分析解決這種問題的優(yōu)秀教師. RogerSmith SQftware Development雜志技術(shù)編輯第1章導論 1. 1統(tǒng)一過程 1. 2 超越統(tǒng)一過程 1. 2. 1 能力成熟度模型 1. 2. 2 OPEN過程 1. 2. 3 過程模式 1. 3 增強的統(tǒng)一過程生命周期 1. 4 細化階段的目標 1， 5 細化階段通常如何進行 1. 5. 1 項目管理工作流 1. 5. 2 業(yè)務建模工作流 1. 5. 3 需求工作流 1. 5. 4 基礎(chǔ)管理工作流 1. 5. 5 分析和設(shè)計工作流 1. 5. 6 實現(xiàn)工作流 1. 5. 7 部署工作流 1. 5. 8 測試工作流 1. 5. 9 配置和變更管理工作流 1. 5. 10 環(huán)境工作流 1. 6 本書的組織形式 第2章 項目管理工作流最佳實踐 2. 1 多團隊開發(fā)管理 2. 2 人員管理 2. 3 招募新人和團隊定義過程管理 2. 4 培訓和教育工作管理 2. 5 文章 2. 5. 1 全球團隊管理 2. 5. 2 協(xié)作管理 2. 5. 3 實現(xiàn)功能特征團隊 2. 5. 4 技術(shù)面試的技巧 2. 5. 5 持續(xù)不斷地進步 2. 5. 6 面向?qū)ο蟮呐嘤?第3章 業(yè)務建模工作流的最佳實踐 3. 1 從業(yè)務建模到業(yè)務流程重組 3. 2 公共的建模表示法 3. 3 文章 3. 3. 1 本質(zhì)言說 3. 3. 2 業(yè)務規(guī)則的邏輯 3. 3. 3 為什么要使用UML 3. 3. 4 實用的UML：將UML加入到項目中的訣竅 第4章需求工作流的最佳實踐 4. 1 用例及其他 4. 2 用戶界面原型制作 4. 3 需求的重要性 4. 4 文章 4. 4. 1 工程化面向?qū)ο蟮男枨?4. 4. 2 撰寫高質(zhì)量需求 4. 4. 3 用例的各種用途 4. 4. 4 從用戶角度進行原型制作 4. 4. 5 打破屏障 第5章 基礎(chǔ)管理工作流的最佳實踐 5. 1 企業(yè)需求和架構(gòu)建模 5. 2 與遺留應用的集成：EAI 5. 3 文章 5. 3. 1 面向?qū)ο蠹軜?gòu)建模：第一部分 5. 3. 2 面向?qū)ο蠹軜?gòu)建模：第二部分 5. 3. 3 混合方法 5. 3. 4 變更架構(gòu) 5. 3. 5 徹底進行企業(yè)應用集成 5. 3. 6 掌握消息代理 5. 3. 7 構(gòu)建企業(yè)架構(gòu) 第6章 分析和設(shè)計工作流最佳實踐 6. 1 以架構(gòu)為中心的建模實踐 6. 2 分離關(guān)注的對象 6. 3 分布式架構(gòu) 6. 4 構(gòu)件和基于框架的架構(gòu) 6. 5 遺留軟件的復用架構(gòu) 6. 6 接口設(shè)計與設(shè)計模式 6. 7 文章 6. 7. 1 回復：架構(gòu) 6. 7. 2 分布式對象設(shè)計 6. 7. 3 構(gòu)件和對象共同體 6. 7. 4 建立遺留鏈接 6. 7. 5 Java接口設(shè)計 6. 7. 6 模式簡介 第7章 測試工作流的最佳實踐 7. 1 概述 7. 2 文章 7. 2. 1 對象測試模式 7. 2. 2 客戶／服務器系統(tǒng)的基于場景的測試 7. 2. 3 快速開發(fā)高質(zhì)量的軟件 第8章 結(jié)束語 附錄A 參考文獻 附錄B 作者索引作譯者簡介 Scott W. Ambler是軟件開發(fā)方法年輕一代的領(lǐng)軍人物之一， 在理論和實踐上的造詣都很深厚. 作為一位高級咨詢師， 他一直積極參與全球各種大型軟件開發(fā)和過程改進項目. 同時， 他還是一位視野廣闊的方法學者， 是《Software Development》雜志的專欄作家， 撰寫了多部頗受推崇的著作， 其中包括《The Object Primer》. 《Agile Modeling》.《The Elements of UML Style》等.

　　ScottW.AmblerScottW.Ambler是敏捷建模方法學的創(chuàng)建者和思想領(lǐng)導者，是軟件開發(fā)方法年輕一代的領(lǐng)軍人物之一，在理論和實踐上的造詣都很深厚。作為一位高級咨詢師，他一直積極參與全球各種大型軟件開發(fā)和過程改進項目。他是RoninInternational公司的高級顧問，該公司是專門提供軟件過程指導、敏捷建模（AgileModeling）及基于對象／組件的軟件架構(gòu)建設(shè)和開發(fā)等方面服務的軟件公司。同時，他還是一位視野廣闊的方法學者，是《SoftwareDevelopment》雜志的專欄作家，撰寫了多部頗受推崇的著作，其中包括《TheObjectPrimer》、《AgileModeling》、《TheElementsofUMLStyle》、《MoreProcessPatterns》等。>>更多作品