精選優質文檔-----傾情為你奉上精選優質文檔-----傾情為你奉上專心---專注---專業專心---專注---專業精選優質文檔-----傾情為你奉上專心---專注---專業摘要

這是我們的項目計劃與跟蹤的內容，在項目實施中使用得很好，我拿出來與大家分享，希望大家多提意見，謝謝！最初的項目計劃不夠精確和準確，不能直接拿來指導我們的日常工作，也不易跟蹤。我們采用三層計劃將計劃中的任務拆分成可跟蹤的小的任務來執行。另外，采用不同周期不同規模的review活動來跟蹤計劃的執行，并不斷地調整我們的計劃。在跟蹤的過程中，由項目經理來負責將每個任務的實際工作量記錄下來，以便最后的統計。

總過程圖

注：

1．根據項目進度定期地（或事件驅動地）進行review和review.

2．偏差包括實際情況與原計劃不相符的任何地方，例如時間安排，人力資源，設備，任務安排，等各方面。

3.Review不僅是查找已執行工作與原計劃的偏差。有時候，根據現階段工作的情況很容易判斷后續工作原定計劃的不合理性，這部分計劃也需要及時修訂。

第一部分不同層次的計劃

項目計劃的目的是為實施和管理制定合理的計劃。三層計劃機制是艾思普公司項目計劃的主要內容。

高層計劃：設計師和項目經理根據用戶需求制定高層計劃，給出項目進行的主要階段和各種需求。此計劃需要經過審核通過后方可執行。為了便于理解，高層計劃也可以稱為月計劃。

中層計劃：項目經理，設計師，以及所有的參與人員共同制定中層計劃。中層計劃是高層計劃的任務分解。中層計劃也可稱為周計劃。

低層計劃：根據中層計劃中的任務安排，每個人制定自己的低層計劃。低層計劃也稱為天計劃。

1高層計劃

在各種估算的基礎上，根據用戶需求給出項目進行的主要階段和進度計劃，就是高層計劃。

進入標準：用戶提出的各方面需求（如成本需求和交付時間要求，等）和軟件項目的開發策略。

人員：設計師，項目經理

內容：

1）階段：項目總體分為哪幾個階段來進行？標準軟件過程是：發現、定義、概念、設計、和實現。根據具體的項目情況，可以將其裁剪和細化。

2）時間：各個階段要求在多長時間內完成？或嚴格要求什么時候完成？

3）資源：按階段闡明需要的資源，包括人力資源和關鍵的設備資源。人力資源說明角色和數量。設備只需提出特殊的或關鍵的設備資源，如需要一個特殊配置的服務器，在系統測試中要搭建模擬環境，等等。

4）退出標準：每階段要達到什么要求才可以退出，即階段完成的要求是什么？

承諾與認可：高層計劃需要客戶和高層管理者的認可，并且有關人員必須被告知高層計劃中與其相關的內容，并得到他們的承諾和認可。比如，通知人力資源部門人員需求，通知財務部門設備要求和經費需求，等等。

注：1）計劃的依據：用戶提出的項目要求，公司采用的軟件工程過程，以及自己的經驗。

2）需要考慮公司的一些實際情況：比如人員調配，員工的技術能力，等因素。三、一個細化的軟件工程概念模型

下圖是筆者理解的軟件工程概念模型（采用UML類圖的語法）：

1、模型概述

圖中，“理論與經驗”和“工具”可以認為是2個比較獨立的概念，其他概念可以被分為4組——“方法論”、“過程”、“目標”、“項目”，分別標以不同顏色。這4組主要概念構成了軟件工程概念模型的骨架，可以描述為：為達到一定的“目標”，我們建立起相應的“項目”，在某種“方法論”的指導下，按照一定的“過程”，生產出相應的軟件“產品”。

從這個模型的骨架中，我們能清晰看到上面精簡模型的影子——（目標，方法，活動）三元組。但顯著區別是，更加強調“活動”的組織和控制方式——“過程”。這是軟件實踐發展的必然結果，因為，隨著軟件產品的復雜程度不斷提高，勢必要更加強調“過程”。RogerS.Pressman在其經典著作《軟件工程：實踐者的研究方法》里就指出：大約每隔5至10年，軟件界就會重定義“問題”，將其焦點從“產品”轉移到“過程”。

2、方法論

“方法論”是在一定“原則與策略”指導下的一套相關的“方法與技術”，而“方法論”可以分為“開發方法論”和“過程方法論”2種。相應的，“原則與策略”可以是開發策略，例如著名的“功能分解”策略；也可以是過程策略，例如迭代模型等“過程模型”，就是過程策略。

應當說，“過程方法論”是隨著軟件實踐的深入，在“開發方法論”產生之后才產生的概念。RogerS.Pressman在其經典著作《軟件工程：實踐者的研究方法》里就指出：大約每隔5至10年，軟件界就會重定義“問題”，將其焦點從產品轉移到過程。在本文后面的章節，筆者將用“過程方法論”的概念解釋“Agile到底是過程還是方法論”的迷惑。

另外，值得一提的是，在實際當中，存在“方法”其實是指“方法論”的現象，在此說明一下。一方面，“方法論”是為完成特定目的一套“方法”，“方法論”和“方法”是一對多的關系；另一方面，實際中人們常將“方法論”簡稱為“方法”，所以也可以認為“方法”是個遞歸的概念，它可以是“原子方法”，也可以是“方法論”。至此，當你同時面對“Agile方法”和“Agile方法論”這2種說法時，就不必迷惑了。

3、過程

“過程模型”是對具體“過程”的抽象，它僅規定了后者的框架，例如瀑布模型規定了“過程”是線性框架；“過程模型”的例子還有螺旋模型、噴泉模型、迭代模型等。一個具體“過程”包括“開發子過程”和“管理子過程”2個子過程，它們分別由一組相關的“開發活動”和“管理活動”組成?！伴_發活動”開發出或再加工“開發工件”，“管理活動”使用“管理工件”，對“開發活動”和“開發工件”進行管理。

“過程開發與改進”是一個特殊的“管理子過程”?！斑^程開發與改進”與其它一般的“管理子過程”相比，后者是為軟件產品的開發服務的，而前者是以開發和改進軟件過程本身為目的。軟件工程大師Osterweil在其論文《SoftwareProcessesareSoftwareToo》中高屋建瓴地指出：軟件過程也是軟件。軟件有一個開發的過程，軟件過程也有一個開發的過程；軟件開發產出軟件產品，軟件過程開發產出過程產品。

RUP是著名的軟件過程產品。CMM是著名的軟件過程改進框架，它本身不是特定軟件過程的定義，它只是建議如何一步一個臺階地改進軟件過程。在本文后面的章節，筆者將從“過程開發與改進”的角度，談談RUP的定制和CMM的定位問題。

4、目標

任何實踐都是有“目標”的，軟件實踐也不例外；比如“開發Bug跟蹤系統”就是一個“目標”的例子?！澳繕恕钡耐瓿桑蕾囉谝幌盗小叭蝿铡钡耐瓿?；比如上述“目標”可以分解為“分析”、“設計”、“編碼”、“實現”等“任務”。

“任務”通常在“方法論”的指導下完成；比如“分析”任務，可以選用“OOA方法論”，也可以選用“結構化分析”方法論。每個“任務”還可以進一步分解成多個“子任務”；比如“分析”可以分解為“需求采集”、“需求分析”、“建立分析模型”等“子任務”。

“子任務”通常使用相關“方法與技術”來實現；比如“建立分析模型”子任務，可以選用“UML建模技術”，也可以選用“結構化建模技術”。

5、項目

“項目”是“目標”、“過程”和“方法論”3者的關聯類；這意味著任何一個“項目”，都采用一定的“過程”，在某種“方法論”的指導下，完成某種“目標”?！绊椖俊钡摹澳繕恕背３＞褪恰败浖a品”本身，但也可以不產出任何“軟件產品”。“項目”是為完成特定“目標”所做出的臨時性努力，可以是建造一棟大樓，一座工廠，也可以是解決某個研究課題，不一而足。

“產品”就是一組“開發工件”的集合，就象經典的“軟件”的定義中說的，“軟件是程序、文檔和相關數據的統稱”?！肮芾砉ぜ笔前殡S“項目”的進行產生的，但它并不是要交付給最終用戶的。

6、其他

現在回過頭來看“理論與經驗”和“工具”這2個概念?！袄碚摗笔歉叨认到y化的知識，“經驗”是尚未進行系統化抽象的知識?！袄碚撆c經驗”是“方法論”的依據，正是在“理論與經驗”的指導下，人們總結出方法論的“原則與策略”，又在后者的指導下，人們將眾多“方法與技術”組織成一套完整的“方法論”?！肮ぞ摺庇脕碇С帧胺椒ㄅc技術”的，好的“工具”可以提高人們的工作效率，減小出錯幾率。

其實圖中還包含了其它一些信息。比如，“方法”和“工具”是多對多關系：一種“方法”可以采用多種“工具”（比如畫UseCase圖可以采用Visio、Rose等多種工具），一種“工具”也可支持多種“方法”（比如Visio可以畫流程圖、UML圖等多種圖）。

又比如，“方法”和“過程”是多對多關系：一種“方法”可以被多種“過程”采用（比如CRC卡方法可以被RUP、XP等多種過程采用），一種“過程”也可采用多種“方法”（比如RUP可以采用OO建模、結構化建模等多種方法）。

篇幅所限，恕不一一列舉。四、軟件工程概念模型的具體應用

下面再舉幾個具體的例子，以說明軟件工程概念模型在快速學習、正確理解和深入掌握軟件工程技術方面的作用。

1、搞清楚Agile是過程還是方法論

當前，“Agile過程”和“Agile方法論”的說法都很流行，令初學者相當迷惑。下面根據軟件工程概念模型的知識，來弄清這個問題。

好的開始是成功的一半，我要做的第一步就是先推翻“Agile是過程還是方法論”這個問法，改問“Agile是過程、開發方法論還是過程方法論”。

第二步，分析《AgileSoftwareDevelopment》一書中給出的Agile模型：

通過對模型的分析，可以看出它是對過程建模：

·如果去掉人和團隊的因素，上面的模型最主要的要素就是過程（Process）、活動（Activities）、產品（Products）和技術（Techniques）了，這顯然是個過程的模型。

·上面的模型中有相當多的和人相關的要素，包括角色（Roles）、技能（Skills）、個性（Personality）、團隊（Teams），對人的因素的極其重視，正是Agile過程的顯著特點。

·Agile過程是面向人的（people-oriented）過程，實施Agile過程的一個關鍵之處是讓人“接受”一個過程而非“強加”一個過程。

我準備提前下結論了——談過程哪能不談它背后的方法論呢——Agile是有它自己的過程方法論的過程。

2、為CMM定位

CMM是一個大家關注已久的話題，CMM標準的提法頗為流行，下面筆者換個角度，根據軟件工程概念模型的探討，將CMM定位為“過程開發與改進的需求和測試方案”。

CMM是軟件過程開發的需求：

·關鍵實踐描述了應當“做什么”，而不是強制規定“如何做”；關鍵實踐的描述就是過程開發的需求項。

·關鍵實踐被分組，成為一些關鍵過程域。相當于需求項的分組，便于管理。

·關鍵過程域的實施都是為了達到一定的目的，從需求的層次角度（請參考Wiegers著陸麗娜譯《軟件需求》一書），可將“目的”理解為“業務需求”，將關鍵過程域理解為“用戶需求”，前者由后者來實現。

·CMM通過定義的這些關鍵實踐和關鍵過程域，覆蓋了我們要開發的軟件過程的主要目的（比如需求管理、產品工程）。

CMM是軟件過程開發的測試方案：

·從原理上，需求就是測試依據。軟件工程中的一條基本原理就是：依據需求進行測試。

·從實施上，我們通常依據需求來編寫測試用例，然后執行這些測試用例。

·BrainMarick更是表述了他的具有革命性的觀點：“我并不想寫出一套用于捕捉用戶愿望的需求，取而代之的是，我要寫出一套測試，一旦這些測試能夠通過，產品就能使她滿意?！北M顯大師風范。

·CMM提供的大量提問單，和測試用例的概念對應得很完美，我們通過這些提問單就可以輕松測試出每一個關鍵實踐進行得怎么樣，進一步測試出每個關鍵過程域完成得如何，該組織的軟件過程的能力成熟度有多高。

3、理解RUP定制

RUP是著名的軟件過程產品，包含了相當優秀的思想，比如：

·為了使風險最小化，RUP引入階段概念和迭代開發模型，以便給開發者足夠多的機會，在付出太多代價之前放棄或調整開發。

·為了使并行最大化，RUP引入工作流的概念，工作流是相關活動的集合，不僅工作流之間也是并行，工作流內部的活動也是可以并行的。

然而，根據具體的實踐情況不同，使用RUP前應當對其進行適當定制。

“RUP定制”屬于“過程開發與改進”中的“過程開發”，而且嚴格來講，是“過程開發的再工程”。再工程（reengineering）是對現有軟件系統或軟件過程的重新開發過程，包括逆向工程、新需求的考慮和正向工程三個步驟。

值得一提的是，“RUP定制”既可以是“RUP剪裁”，也可以是“RUP擴充”。RUP剪裁大家討論的比較多了，有興趣的讀者可以閱讀本文參考文獻中所列的《RUP的剪裁原理和剪裁過程》一文。

著名的RUP擴充的例子有：

·RoninInternational公司將RUP擴充成為EUP。

·再比如愛立信在RUP的基礎上進行擴充，開發出ERUP作為公司范圍內的框架結構。

五、軟件工程概念模型的啟示

1、軟件工程，一門實踐的科學

通過對軟件工程概念模型的研究，強烈地感覺到，軟件工程是一門實踐的科學——它的出發點和最終目的是指導實踐?；诖?，我們至少應當注意2點：

·從時間上，實踐是發展的，基于實踐的軟件工程學科也必然是發展的，比如近幾年，軟件工程領域的發展就相當大。我們必須意識到這一點，不斷學習新知識，才能適應軟件實踐的需要。RogerS.Pressman說：“軟件工程將發生變化——對此我們可以肯定。”

·從內容上，軟件實踐的差異是巨大的，我們不能生搬硬套。正如AlistairCockburn所說：“不同的項目需要不同的方法”。

2、軟件過程，合適的才是最好的

據我所知，好的軟件過程在不少人的腦子里，是一個“越……越……”的答案。比如，文檔越多越好，分工越細越好，控制粒度越小越好，等等。還有，人們認為好的軟件過程是可以照搬使用的，我聽到過類似“我在某某大公司都是……”的抱怨。

其實通過軟件工程概念模型的探討，我們可以看到，軟件過程是整個模型很多節點中的一個而已，這意味著軟件過程和很多因素有著影響、被影響的關系：

·軟件類型、軟件規模、軟件重要程度、開發人員素質、管理和支持人員素質、合作單位素質等，都是影響軟件過程制定的因素。

·而且，且不可單純認為軟件過程僅僅涉及到開發人員，用戶、合同確定者、投標者、項目管理者等，都可以成為軟件過程的“涉眾”；也就是說，他們都可能是待開發的軟件過程的用戶，應當收集他們對軟件過程的要求。

3、對個人的啟示

分析了軟件工程概念模型，可以看出，從某種角度，可以認為軟件產品是多種技術協作的結果。技術的協作最終表現為個人的協作，軟件工程概念模型對個人有何啟示呢？

·明了自己知道的和不知道的，尊重他人，是一個團隊的必要基礎。

·注重團隊成員間技術的互補性和全面性。

4、呼喚高層次人才

看著模型，想著近年來國際上軟件工程的巨大發展，深感國內在軟件工程領域的落后，“透過變化看趨勢、透過技術抓原理、把握軟件工程發展脈搏”的高層次人才太少。

我輩尚需努力。。2簡化原型法需求分析的第一個階段

管理信息系統屬于數據庫應用。數據庫應用需求分析應該圍繞數據，而不是功能展開，因此應該首先解決"有什么"，然后再明確"做什么"[4]。第一個階段就是要解決"有什么"，即由項目經理與用戶進行協商，確定系統的技術協議，因此可以稱為技術協議階段。技術協議需要開發方的項目經理與用戶單位的技術主管簽字并蓋章，并以合同附件的形式存在。技術協議的主要內容有：系統的邊界、系統處理的業務、與其它系統的接口、工程的進度控制、培訓安排和技術服務承諾。

2.1系統的邊界

系統的邊界規定系統覆蓋的作業范圍，主要有地理邊界（規定系統運行的部門、分支單位等）、操作員范圍（規定操作系統的所有操作員身份、分布和大致權限）和業務范圍（規定系統處理的業務，對于不處理的邊沿業務特別明確指出）。

2.2系統處理的業務

系統處理的業務涵蓋系統處理的所有業務，包括各種業務的描述、數據來源、實現要求。但是業務規定不要求過細，可以對應實際系統中的一個模塊。如：電力MIS中輸電設施管理子系統中的線路設備管理，不詳細描述線路設備管理中的所有功能。

2.3與其它系統的接口

與其它系統的接口明確規定接口的系統、功能和實施單位。在接口的實施單位中明確是由開發方完成，還是由開發方協助第三方完成。

2.4工程的進度控制

工程的進度控制規定工程的開始、結束日期和具體工程項目的名稱、完成時間、地點、完成標志及責任分工。具體項目一般包括：采購設備到達現場、采購設備安裝調試、完成網絡布線、開發準備階段、業務需求調查、系統分析和設計、軟件編制、現場調試、數據準備及錄入、功能確認、試運行和系統驗收。責任分工規定雙方對于具體項目的工作內容和配合方式。在配合方式中規定人員組織方式、人員素質要求、提供的設備和場所。完成標志規定具體項目完成提供的文件名稱和要求，如：網絡布線驗收報告和硬件設備驗收報告等。

2.5培訓安排

訓包括操作員和系統維護人員的培訓。培訓安排包括每種培訓的人員數量、培訓內容、培訓時間、地點、組織方式和教材，并規定教員和學員的素質要求，及培訓后學員達到的水平。

。3簡化原型法需求分析的第二個階段

如果說第一個階段解決"有什么"的問題，那么第二個階段解決"做什么"的問題。主要工作有需求調查準備、到用戶單位進行需求調查分析和進行需求評審。

3.1需求調查準備

需求調查準備工作，在系統的技術協議簽訂后，嚴格依照技術協議進行，主要有向用戶單位發放業務調查表、建立需求分析文檔原型和建立系統簡化原型。業務調查表在系統的技術協議簽訂后，立即通過傳真發送到用戶單位，要求用戶單位在需求調查人員到達現場之前完成。業務調查表內容包括：具體業務的名稱、上級業務、下級業務、發生條件、處理的數據和詳細流程（處理崗位、處理方式和審核細節等）。需求分析文檔原型是根據技術協議編寫的需求分析說明書原型，它的格式與標準的需求分析說明書相同。其中的狀態遷移圖和各種表證單書等不明確的內容，采用相似系統的或由系統分析人員根據技術協議和以往經驗設計。

系統的簡化模型根據技術協議的要求，仿照相似系統設計。簡化模型采用可視化的數據庫編程語言設計，一般采用數據庫應用開發人員熟悉的PowerBuilder(PB)或Delphi。簡化模型的主要設計要求有：1）充分考慮系統的設計與實現，不得與實際系統脫節；2）盡量仿真實際系統的操作界面，與實際系統的操作過程完全相同；3）可以單機安裝運行，不與實際數據庫連接；4）演示數據的存儲可以通過文本文件、單機的數據庫或PB外部數據源的數據窗口；5）對于界面中容易誤解或難以理解的操作，在功能幫助按鈕中給出說明；6）界面中難以實現或工作量很大的功能，以標注方式詳細說明；7）運行穩定，并比實際系統對硬件要求低。

3.2需求調查分析

需求調查分析在確認需求調查準備的三項工作完成后，由開發單位的系統分析人員到用戶單位進行。系統分析人員與用戶單位安排的業務主管共同討論業務調查表和系統簡化原型，并不斷修改完善系統簡化原型和文檔原型，最終形成共識，并要求業務主管在需求分析說明書上簽字。最終系統簡化原型和源代碼留在用戶現場，便于系統的操作員進一步理解分析，直到最終掌握；而且有利于提出進一步的改進意見。改進意見可以隨時通過郵件或傳真直接發到開發單位，或由用戶單位的系統維護人員修改簡化原型后，隨時發到開發單位，從而便于開發人員及時修改系統的設計和編碼。

3.3進行需求評審

需求評審一般由用戶單位組織，評審團成員由同行專家、系統分析、設計和測試人員組成。評審的依據不僅有需求分析說明書，還有系統簡化原型；同時在評審過程中，系統簡化原型不斷進行優化。評審的目標是要求需求分析說明書具有正確性、可行性、必要性、具有優先級屬性、可驗證性和無二義性[5]。需求評審報告作為對需求分析的補充和修正，由雙方負責人簽字，以需求分析說明書附件的形式存在，同樣指導下一步的系統設計工作。4幾點說明

1、此方法適合各種MIS工程的需求分析，特別適合致力于某一領域MIS開發的軟件公司。采用此方法，開發同類項目越多，需求分析工作的效率越高。

2、在需求分析過程中，由于需要設計系統簡化原型和文檔原型，并充分考慮到系統的設計與實現，因此與其它需求分析方法向比，提高了對需求分析人員的要求。在實際工作中，一般由資深的軟件分析和設計人員進行。

3、此方法不僅適合MIS軟件工程，同樣適合其它大型軟件工程。

4、由于需求分析工作本身的難度和重要性，此方法同樣要求用戶單位和需求分析人員對需求分析所有工作內容，引起足夠重視；科學安排需求分析工作步驟，某些步驟可以同時進行；所有工作步驟不得應負或疏忽。

5結束語

目前簡化原型法已經在多個電力MIS工程中應用，大大提高了需求分析的工作效率。實踐證明，簡化原型法具有以下特點：1）簡化的系統原型開發工作量大大降低，修改和補充方便；2）簡化原型大大縮短了需求分析人員與業務主管之間的距離，便于交流；并大大加強了需求分析人員與業務主管對系統的認識，有利于發現和解決問題；3）簡化原型的設計提前考慮了系統的設計與實現，大大降低了軟件工程的風險；4）簡化原型增加了系統操作員對實際系統的認識，大大簡化了工程實施后系統的操作培訓；5）簡化原型可以直接指導工程的設計和編碼，便于系統開發的組織。這種方法也可以用于其它軟件工程，對于其它需求分析方法的改革也具有指導意義。

參考文獻

[1]毋國慶，朱立松等.嵌入式實時系統的軟件需求檢測.軟件學報,2002.5(13).

[2]呂夢雅，陳晶.面向對象的原型法在需求分析中的應用.河北省科學院學報,2002.3(19).

[3]王繼成，高珍.軟件需求分析的研究.計算機工程與設計,2002.8(23).

[4]張峰嶺.數據庫應用的需求分析研究.計算機工程與應用,2002.18.

[5]李師賢，張珞玲.需求分析的常見問題及其對策分析.計算機工程,2002.1(28).。2中層計劃

將高層計劃的任務進一步細化為每個人或每個小組在大約一周時間的工作，就成為中層計劃。

進入標準：高層計劃已制定且通過審核。

時間：在進入每個大的階段之前，本階段的中層計劃一定要明確，并取得團隊的認可。本階段的中層計劃是開始本階段的主要輸入。

人員：項目經理及設計師領導項目團隊共同制定中層計劃。中層計劃將把任務具體到團隊的每個人。

內容：

1）任務：項目的每個階段可以拆分為哪些任務？

2）人：每項任務的責任人是誰？一項任務可能不止一個人完成，但必須指明一個負責人（Owner）。

3）設備資源：什么時候需要什么樣的設備資源，需要給出設備的具體要求。如性能要求，配置要求等。

4）時間：每項任務要求在多長時間內完成？或嚴格要求什么時候完成？

5）任務之間的依賴關系：各項任務之間有無依賴關系？是什么樣的依賴關系？

6）里程碑：闡明一些關鍵的事件點，如關鍵人員或設備的到位期限，什么時候審核，等等

承諾與認可：保持與高層計劃的一致性，每項任務的估算得到執行者的認同，有依賴關系的任務安排要得到相關人員的認可。

注：1）需要邀請有測試經驗和部署經驗的人分別參與測試和部署的工作計劃，他們會幫助團隊制定出較合理的中層計劃。

2）當中層計劃與高層計劃不一致時，將中層計劃重新估算一遍。如果還是與高層計劃不一致，則以中層計劃為準，要求修改高層計劃

3低層計劃

每項任務的執行者根據中層計劃將自己的任務細化到每一天，即低層計劃。

進入標準：中層計劃已制定且項目團隊整體認可。

時間：在每周周一的早會之前，制定出本周本周或兩周內每天的計劃。

人員：低層計劃一般由具體執行任務的每個人來制定。這將是每天Teammeeting的依據。

內容：每天的任務和需要提交的文檔。

承諾與認可：要求每個人計劃中特定時間所要求的支持得到支持提供者的認可。另外，要求每個人的計劃符合中層計劃，與其他人的計劃進度沒有沖突。

注：在實際開發過程中，往往有些工作不能拆分到每一天。就是說，一件事情需要幾天來完成。如果本任務不在關鍵路徑上，而且與其他人員的工作關系比較獨立，可以不拆分此任務，由執行者本人掌握進度。否則，需要將任務盡量拆分開來，按內容劃分為幾部分，或用百分比來劃分，以便更好地掌握整個項目的進度。

4三個計劃的關系

計劃更改的時候，一定要保持各層計劃的一致性。高層計劃會因中層計劃的更改而調整，低層計劃會受中層計劃的影響。

。第二部分不同周期的Review

項目跟蹤的任務是對照計劃評審和跟蹤軟件完成的情況和結果，根據實際完成的情況和結果調整這些計劃。艾思普公司的Review工具是項目跟蹤的主要內容。

根據目的和周期的不同，項目跟蹤中用到3種Review工具：dailyreview,Peerreview,和Progressreview。

1Dailyreview

目的：跟蹤團隊成員每天的任務完成情況，給團隊提供一個交流的機會。

時間：在每個工作日的開始。一次Dailyreview一般持續10~15分鐘。

形式：以teammeeting的形式進行。

參加人：團隊所有人員（包括項目經理和設計師）。

活動：

1）跟蹤團隊成員每天的任務完成情況

2）交流相關問題

2Peerreview

目的：跟蹤項目每周的任務完成情況，交流相關問題。

時間：每周進行一次。Peerreview一般不超過1小時。

形式：會議形式。由項目經理來主持。一般要求項目經理提前將會議邀請發給大家。