專業信息系統項目管理師網站|培訓機構|服務商(2020信息系統項目管理師學習QQ群:89253946,客服QQ:270019001)

軟題庫 培訓課程
當前位置:信管網 >> 信息系統項目管理師 >> 軟考論文 >> 文章內容
信息系統項目管理師范圍管理論文論點論述部分范文
來源:信管網??2019年10月11日? 【信管網:項目管理師專業網站所有評論

信息系統項目管理師范圍管理論文論點論述部分范文

項目范圍管理是項目管理中至關重要的管理知識領域,項目范圍管理主要包括:收集需求,定義范圍,制定WBS,范圍確定,范圍控制等過程。因本次嵌入式軟件委托開發項目的研發規模大,項目建設期長,需要總公司和中國受委托開發團隊之間的協同開發,作為中國受托開發的虛擬團隊,于是就有了下面三個在范圍管理上的比較有代表性的困難。其一,在無法直接與客戶進行F2F溝通,需求曖昧。其二,各個設計需求之間范圍影響不同,難免會產生前后矛盾。其三,該項目成果物繁多,為范圍確認與逐一驗收帶來了阻礙。


針對上面三個困難,在本項目的范圍管理各個過程中,我主要做了以下的工作。


1. 收集需求和范圍定義


因本次新追加了功能都已經在XXXX上實現,其他小功能也均在從其他不同的產品線上實現功能,所以需求就是一句話,讓我們參照既有產品功能,然后將功能全部移植到XXXX上。但XX和XXXX機屬不同的代碼基線庫,且原理的不同,所以是無法做到100%功能移植的。這就給我方收集需求上帶來了困難。


針對上面所說的需求分析的困難,我采取了分析產品,系統交互圖,引導式研討會等技術獲取和確認需求。我從公司項目資產庫中調取了XXXX機參照功能的機能說明書,結合測試報告書。分析完現有的文件后,調來了實機,和團隊成員一起根據測試報告書,一起在實機上動作了一下需要移植的功能,在充分理解機能以后,使用UML測試用例圖對功能進行了建模,同時也要求對每張圖都要明確系統輸入和輸出。在團隊內部評審后,我便根據干系人登記冊的內容,逐個功能與干洗人召開需求討論會,在用例圖的基礎上討論定義的機能需求。同時重點說明了經過我方可行性分析后,因框架的差異無法移植實現的需求。在視頻會議上引導干系人聽取我方的意見后,得到了干系人關于需求的詳細反饋。在稍作修改后,各個功能的需求逐漸清晰,在UML用例圖的基礎上,做成了需求文件列表,然后進行了范圍定義,做成了范圍定義說明書。在發給干系人得到了承認后,收集需求和范圍定義的工作圓滿結束。


2. 創建WBS(工作分解結構)和變更設計TM


創建工作分解結構是把項目可交付成果物和項目工作分解成較小的,更加易于管理的組件的過程。因本項目建設規模大,樹形結構的WBS不能很好的使用,所以需求的分解使用了列表形WBS。根據項目的特殊性和每個需求的特點,我和團隊成員一起在分解需求的同時,加上了每個需求的背景和理由并把這些內容一并寫入并作為了項目的范圍基準。正式進入開發階段后發現了一個問題,各個設計需求之間范圍影響不同,有些需求在考慮設計實現的過程中,會產生前后矛盾的情況。一般情況下如果確認了一個變更點之后馬上修改代碼,這樣就很可能會沒有注意到模塊之間的相互影響和對產品現有功能的影響,而造成返工。針對這個問題,我引入了XDDP派生開發中的變更設計TM來解決。


變更設計TM是XDDP派生開發的重要可交付成果物,它的格式類似于需求跟蹤矩陣,每一行登陸分解后的樹狀結構WBS,與根據矩陣不同的是每一列登陸所需要修改的源代碼文件的名字。它要求針對每一個變更內容,不要馬上進行修改,首先將要修改的思路根據將要修改的源文件的不同寫入到變更設計TM里面,通過自我評審和團隊內部評審來充分分析變更設計所產生的對現有代碼的影響范圍,在變更設計TM的做成過程中,出現了多個需求改同一個C源文件甚至是同一個函數的情況,通過作成變更設計TM,在未進入編碼階段前,就清楚地看到了各需求之間相互影響,與現有功能的沖突部分,因為用分解后的WBS定義了變更設計TM,且用該文件也較好地跟蹤了需求的實現情況,各個設計需求之間范圍影響而導致質量下降的問題并未出現在本項目中。


3.范圍確認和控制


因為項目周期長,規模大待實現的功能和需要交付的成果物繁多,變更需求小而多,如果不能妥善安排項目的驗收確認過程,將會在項目收尾時出現混亂情況。針對這個問題,我使用變更設計TM來完成需求實施情況跟蹤的同時,采用三段式驗收方法,即阿爾法版,貝塔版和最終版來實施成果物的驗收。因為每個需求變更對應一張JIRA票,于是每完成一個需求,在將成果物記到JIRA后,要求客戶方負責人在一周內確認驗收。驗收有問題通過JIRA聯絡。驗收完再JIRA上打上標簽以便日后查找。使在各個子需求子功能順利驗收后,更新變更設計TM。然后在關鍵里程碑上再次核對成果物采取聯合驗收,為最終項目的驗收提供有效保障。


在范圍的控制上,我使用JIRA票來管理變更。將實施變更管理流程的過程和結果都分批次反映到JIRA票上。我將變更分成了三類,新增功能,既有功能變更,完善性變更(代碼重構),并在JIRA上定義優先級,根據優先級高低,決定阿爾法版驗收時間,同時在JIRA票上定義好子需求驗收的方式。有些完善性的內部變更,因為考慮到項目整體情況范圍蔓延和質量鍍金等因素,和客戶方協調后更改為了次機種檢討項目。






發表評論  查看完整評論  

相關內容

推薦文章
合作網站內容
内蒙古时时彩开奖号