IPMS（Integrated Project Management System），是一個為上海貝爾阿爾卡特某移動事業(yè)部門定制化開發(fā)的多系統(tǒng)集成項目管理系統(tǒng)，其目標是通過對該部門整個開發(fā)管理工具環(huán)境的集成來達到對項目的實時跟蹤和管理，以及數(shù)據(jù)的采集和度量。然而，一個客觀事實是，國內(nèi)大量的中小型項目中的絕大多數(shù)都存在著需求不明確性的問題，伴隨而來的是大量需求變更所帶來的開發(fā)風險。那么面對這樣的客觀事實，是否意味著項目經(jīng)理根本無法應對這樣的問題呢？真正的項目經(jīng)理又會如何挑戰(zhàn)需求不明確和需求變更所帶來的開發(fā)風險呢？
[案例背景]
背景描述1: 隨著阿爾卡特與朗訊科技的合并，該移動事業(yè)部門也將與原兩家公司的多個部門進行合并。合并后的新部門將采用全新的產(chǎn)品線定義，并實施新的項目管理流程。在這樣的情況下，以前的IPMS系統(tǒng)已經(jīng)無法滿足該事業(yè)部門對項目的流程管理，IPMS系統(tǒng)三期開發(fā)勢在必行。
背景描述2: IPMS系統(tǒng)作為一個集成化的管理系統(tǒng)與眾多功能強大的軟件系統(tǒng)集成，其中包括ClearQuest，一個強大的事務狀態(tài)管理軟件。原先IPMS與ClearQuest通過一組ClearQuest軟件預先定義的API進行數(shù)據(jù)通訊。
[提出問題]
由于合并的時間過于倉促，以及部門之間的項目數(shù)據(jù)定義和管理流程的不同，導致IPMS三期開發(fā)的需求極不明確，整合后的新部門內(nèi)部還在為部門的項目管理的流程定義和系統(tǒng)可能的功能修改爭論不休，在這樣的情況下，項目進展十分緩慢。
IPMS三期的第一個迭代中有這樣一個非功能性需求，即ClearQuest的版本升級，隨之而來的一個風險便是，伴隨著ClearQuest的版本升級，沒有人知道原版本中與IPMS數(shù)據(jù)通訊的API接口是否可以向下兼容。
[解決方案]
1．基于現(xiàn)實的問題，即該事業(yè)部門確實無法在很短的時間內(nèi)協(xié)調(diào)和構思出統(tǒng)一的系統(tǒng)需求，以及部門希望盡快將部分功能使用起來的愿望，項目組采取了基于需求基線化管理的迭代開發(fā)。項目組采用了合適的開發(fā)步驟，首先基于目前的需求不穩(wěn)定性項目組決定了以一個月為開發(fā)的迭代周期；然后在策劃期提取出一組客戶的高端需求，通過對需求的簡要分析和工作量估算，并依據(jù)一組參數(shù)（比如重要性，緊急程度和需求的穩(wěn)定程度）規(guī)劃出一個月內(nèi)（一次迭代期）的項目需求；對這些需求建立基線，一旦需求的基線確立，那么在這個迭代周期內(nèi)的需求應該是穩(wěn)定的；后項目組在一個迭代周期內(nèi)，通過依據(jù)CMMI的流程對系統(tǒng)進行三期開發(fā)。
通過這樣的方式，能夠盡可能的降低需求不明確所帶來的開發(fā)風險，增強需求的可管理性，但是如果在迭代內(nèi)部發(fā)生了需求的變更又該如何處理呢？
2．項目組通過對風險可能的發(fā)生時間點和閥值的控制，來管理風險的危機。
項目組首先識別出了ClearQuest升級后的API兼容性風險；同時，通過討論，項目組確定了這個風險可能轉化為問題的時間點，即一旦完成三期對項目注冊功能的修改后，必須在測試時確定IPMS中注冊的項目數(shù)據(jù)是否可以正確的被保存入ClearQuest中，我們可稱那個時間點為A時間點；當項目的開發(fā)活動快到達A時間點之前，項目組安排人力對新版本ClearQuest中的相同API進行了簡單的功能原型測試，測試結果表明確實存在兼容性問題；項目組立刻決定修改項目計劃，并在原先的風險預留的時間段內(nèi)增加了對API兼容性問題的處理事務，從而解決了ClearQuest版本升級可能導致的系統(tǒng)無法正常注冊項目的重大問題，使得項目得以平穩(wěn)開發(fā)
[案例評析]
在軟件項目開發(fā)過程中，對于開發(fā)模型的選擇，需要在項目定義過程中明確。CMMI V1.2 For dev中，過程域IPM[注：4] 的SP1.1 Establish the Project’s Defined Process有明確要求。在上述案例中，提到的迭代式開發(fā)模型為眾多開發(fā)模型中的一種，而在項目中具體要使用哪種模型可從組織項目定義過程中進行選擇。軟件開發(fā)模型通常有以下幾種：瀑布型，迭代型，原型等，具體選擇何種，需要視項目的特點而定；上述案例的主要特點是需求的不穩(wěn)定性，選擇迭代式開發(fā)模型無疑是一種較好的選擇�？梢钥吹�，上文中有提到“基線化”一詞，有實施CMMI的企業(yè)或參加過CMMI過程改進活動的個人對這個詞一定不陌生。CMMI模型中，要求對過程的產(chǎn)出物進行配置管理。過程域CM[注：5]中，SP1.3 Create or release baselines 要求建立并發(fā)布基線�；�是經(jīng)過評審并通過的一系列產(chǎn)出物，基線建立以后，后續(xù)的開發(fā)工作需以此作為基礎。上述案例中，之所以提出基線化一詞，意在強調(diào)階段性地需求需要經(jīng)過評審并確定之后，以此指導后續(xù)開發(fā)工作。此外，越來越多的人關注軟件項目開發(fā)過程中風險管理環(huán)節(jié)。風險管理過程是用于識別潛在的問題，并策劃應對策略，在需要時實施相應動作以消除不利影響。在CMMI模型中，有專門一個PA對風險管理進行描述和要求。上述案例中，正是識別到由于ClearQuest升級而帶來的API不兼容性風險，并針對于風險采取了利用閥值控制等措施。軟件開發(fā)過程中，我們會遇到各種各樣的風險，而且這些風險一旦發(fā)生，會給項目的順利進行帶來嚴重威脅，因此在項目計劃時，要制定一個嚴密的風險管理計劃，并且對于風險情況進行嚴格的跟蹤，這樣才可能把風險對項目所帶來的影響降低，至小。
注：
1：基線化：在配置管理系統(tǒng)中，基線是一個CI（配置項）或一組CIs在其生命周期的不同時間點上通過正式評審而進入正式受控的一種狀態(tài)，而這個過程被稱為“基線化”。
2：迭代：迭代是為了完成一定的階段性目標而所從事的一系列開發(fā)活動，屬于開發(fā)模型中的一種。
3：風險管理：風險管理指對項目風險進行識別、分析、并采取應對措施的系統(tǒng)過程。它包括盡量擴大有利于項目目標事項發(fā)生的概率與后果，而盡量減小不利于項目目標事項發(fā)生的概率與后果。
4：IPM:集成項目管理，為CMMI中一過程域。
5：CM:配置管理，為CMMI中一過程域。
