信息系統項目管理師學習資料大全-文庫吧

【正文】 變需求又在所難免，基于外部環境的變化而出現改變用戶需求的情況是一種客觀需要，而且迅速應對客戶的需求變更是顧客本位的內涵之一。在這種情況下，只能依靠科學的產品控制技術來順應這種要求。當改變需求時，為了保持軟件各個配置成分的一致性，必須實行嚴格的產品控制，其中主要是實行基準配置管理。所謂基準配置又稱基線配置，它們是經過階段評審后的軟件配置成分（各個階段產生的文檔或程序代碼）。基準配置管理也稱為變更控制：一切有關修改軟件的建議，特別是涉及到對基準配置的修改建議，都必須按照嚴格的規程進行評審，獲得批準以后才能實施修改。避免開發人員對軟件隨意進行修改。　　。從提出軟件工程的概念開始，人們一直把主要精力用于研究各種新的程序設計技術。從60年代末提出的結構程序設計技術到最近的面向對象技術，人們不斷創造先進的程序設計技術。實踐表明，采用先進的技術既可提高軟件開發的效率，又可提高軟件維護的效率。　　。與其他有形產品不同，軟件是看不見摸不著的邏輯產品。軟件開發人員的工作進展情況可見性差，難以準確度量，從而使得軟件產品的開發過程比一般產品的開發過程更難以評價和管理。為了提高軟件開發過程的可見性，更好地進行管理，應該根據軟件開發項目的總目標及完成期限，規定開發組織的責任和產品標準，從而使得所得到的結果能夠清楚地審查。　　。該原則意味著，軟件開發項目的組成人員的素質應該好，而人數則不宜過多。開發小組人員的素質和數量是影響軟件產品質量和開發效率的重要因素。素質高的人員的開發效率比素質低的人員的開發效率可能高幾倍至幾十倍，而且素質高的人員所開發的軟件中的錯誤明顯少于素質低的人員所開發的軟件。此外，隨著開發小組人員數目的增加，因為交流問題而造成的溝通成本也急劇增加。因此，構建和維持少而精的開發團隊甚至標桿團隊是軟件工程的一條基本原理。　　。遵循上述6條基本原則，就能夠按照當代軟件工程基本原理實現軟件的工程化生產，但是，僅遵循上述6條原則并不能保證軟件開發與維護的過程能趕上時代前進的步伐，能跟上技術的不斷進步。因此，勃姆提出應把承認不斷改進軟件工程實踐的必要性作為軟件工程的第七條基本原則。按照這條原理，不僅要積極主動地采納新的軟件技術，而且要注意不斷總結經驗。　　威格的成功軟件項目管理秘訣　　過程影響（Process Impact）公司的首席咨詢顧問卡爾。威格（Karl ）在其《成功項目管理秘訣》（Secrets of Successful ProjectManagement）一文中總結了成功項目管理的20條秘訣：　　構筑基礎　　；　　、約束和自由度；　　；　　。　　規劃工作　　；　　；　　；　　；　　；　　。　　估算項目　　；　　％的時間；　　；　　；　　；　　；　　。　　追蹤進展　　；　　，才認為該任務結束；　　。　　麥克康奈爾的成功軟件項目十大要決　　史蒂夫。麥克康奈爾（SteveMcConnell）在《成功軟件項目的十大要決》（10 Keys to Successful SoftwareProjects）中闡述了成功軟件項目的十大要決：　　；　　、完整的、書面的需求；　　；　　；　　；　　；　　；　　；　　；　　：軟件來源于人。在組織間跨項目組加強推廣學習優秀經驗以往對項目總結的認識不夠，很多時候也就是寫寫PPT或者開個會，很多經驗沒有能被辨識出來成為案例，也就不能給大家分享。特別是很多教訓，人性的問題，沒有被說出來，畢竟說出自己的不是不是每個人都能做到。導致教訓庫不能不斷豐富，因此前人吃虧，后人無法繼承到有效的經驗。　　前段時間進行2008年度總結的時候，業主提出接觸我們這么多項目，我們每個項目經理的風格都不一樣，項目的成功與否太依賴于項目經理個人的能力。我想我們不是要讓每個人都沒有自己的風格，項目經理當然有能力水平的高低，當然有不同的價值體現。業主其實就是在說我們的項目實踐必須積累。　　在之前的博文《業主的改進意識讓我驚訝，我們應該更加積極地看待和推進CMMi的改進！》中講到，一個業主的項目經理對口我們幾個項目經理，A項目經理做得好的，業主方項目經理肯定會將A做得好的地方來要求公司的另一個項目經理B。如果我們自己不傳授這種經驗，那才是傻子。　　使用即將推行的CMMi的規程，重新Review一下2008年的各個項目，從中去分析各個項目組的強處以及弱項，從規程中掃漏洞，審視項目組的那些活動執行的力度和弱項之間的關系，對于來年指導項目建設是非常有幫助的。今天在內審會議總結上，同事WN說得好，我們現在的項目經理花了很多時間在做事，其實缺少了時間思考如何去做事！管理不僅是規范、監督，還有教練一職。　　故事一則：　　在組織間跨項目組加強推廣學習優秀經驗，除了會議交流、專題培訓，還可以去現場實地體驗加強感性認識（呵呵，共產黨宣傳的那一套都要學習用上）。上次說到項目O和項目C整合上線，整個上線持續了近三天時間，有很多地方值得總結。今天剛好有項目T正在組織部署上線，項目T的技術經理CC做為培訓講師以往培訓過兩次有關部署的工作，項目C的經理C當時也聽過CC的課程，在沒有和CC打招呼的前提，帶上項目O和項目C的兩位同事L和C到現場去抽查觀摩，能夠更加有感觸其他同事的優秀實踐。　　到了現場，才知道項目T晚上6點才開始部署，因此安排兩個項目的項目經理/技術經理進行現場的交流。在簡單介紹了此行的目的后，CC首先發言，詢問C上次部署的過程中計劃和實際工作最大的出入在那些地方？通過近一個小時的訪談，同事C和L認識他們有不少改進的問題，這里講最重點一點：項目組C和項目組O在系統的正式部署前，缺少完整的演練。雖然有部分的演練，但是沒有通過演練將可能的問題辨識出來。也因為如此，吃虧最多的遷移方案中的校驗問題，沒有能夠提前暴露。　　涉及到新舊兩個系統的遷移，數據需要從系統O遷移到系統C，采用的方案是C直接訪問O的數據方式，表面看這種方式最簡單最直接，但是編寫遷移和校驗程序的同事都必須必須清晰了解C系統和系統O的業務邏輯，而實際由于邏輯覆蓋不全面，導致校驗的工作不完整，只使用抽樣的方式即花了大量的人力（校驗一個抽樣數據，需要花20分鐘人力），也導致有大量的遷移漏洞需要補救。　　同事CC告訴C，應該采用接口交互表的方式，約定好規格，系統O的同事熟悉O的業務邏輯，負責將數據遷移到接口表，再由他們進行業務邏輯的檢查，因為他們熟悉舊系統的邏輯啊！檢查完畢后，才由C負責從接口交互表中提取數據，C了解新系統的新業務邏輯，對接口交互表進行邏輯檢查后，提取數據轉換到新的系統。采用兩階段的遷移，由熟悉舊系統的同事做應該做的事，讓新系統的同事做他該做的事、熟練的事，看似復雜反而簡單！　　我在旁邊插了話，其實如果舊系統是其他公司承建的，可能同事們就能想到兩階段遷移的接口交互表方式，可是我們兩個系統由于是同一個部門承建，我們把部門邊界和系統邊界給混淆了，反而欲速而不達。在網頁中用JS函數控制Flash動畫播放 一、介紹與Flash動畫控制有關的javascript函數：函數名使用作用play()()播放Flash動畫stopplay()()停止播放Flash動畫rewind()()停止播放Flash動畫并返回第一幀totalframes()()返回Flash動畫總幀數gotoframe(int num)(int num)轉到指定幀 二、程序代碼： html head script language=javascript function init() { = } /script /head body onload=init() bgcolor=FFFFFF bgproperties=fixed fieldset legendfont color=FF0000控制Flash動畫/font/legend form name=changeframe font color=800000 Flash動畫幀數:/fontfont color=000080binput name=totalfrm type=text size=4 value=1 disabled /b/fontfont color=800000 輸入第/fontbfont color=000080input name=framenum type=text size=4 value=1/font/bfont color=800000幀,再點擊指定幀。/font /form a href= onclick=javascript:()font color=800080播放/font/a bfont color=000080 /font/b a href= onclick=javascript:()font color=800080停止/font/a font color=000080 b /b/font a href= onclick=javascript:()font color=800080停止返回第一幀/font/a bfont color=000080 /font/b a href= onclick=javascript:()font color=800080指定幀/font/acenter /fieldset OBJECT classid=clsid:D27CDB6EAE6D11cf96B8444553540000 codebase=,0,0,0 ID=wgzc WIDTH=500 HEIGHT=100 PARAM NAME=movie VALUE= PARAM NAME=quality VALUE=high PARAM NAME=bgcolor VALUE=FFFFFF EMBED src= quality=high bgcolor=FFFFFF WIDTH=500 HEIGHT=100 TYPE=application/xshockwaveflash PLUGINSPAGE= /EMBED /OBJECT /center /body /html以WBS為主線的集成項目管理任何流程或業務在我們學習的過程中始終都有一個主線，比如說知識管理的基礎或主線是知識庫和知識地圖，ERP的數據基礎是ITEM和BOM，主線是需求訂單MRP生產計劃和采購計劃。對于產品數據管理PDM的主線是產品結構，對于CRM客戶關系管理的主線是營銷市場策劃銷售計劃預測項目合同。而對于項目管理其基礎是WBS工作結構分解，其主線是項目結構項目WBS工作包活動任務。這條主線涉及到PMBOK里面的范圍管理和進度管理兩方面的內容。對于范圍管理最終的輸出就是范圍說明書和WBS，而對于進度管理則輸入是WBS，需要進行活動定義分解和排序，最終得到的進度表。在項目的執行過程中我們是按照具體的活動任務在執行，在執行的過程中會產生使用資源，消耗成本，產生文檔和各種輸出，進行設計開發，集成，評審和質量控制。　　我們活動分解的單位是到了具體的任務，但是我們產品的最終集成，我們的成本核算和掙值管理是不能到活動任務的。因此WBS在整個項目管理中就起到了重要作用，其作用不僅僅在前期確定項目范圍和制定項目的進度計劃，更多的是后期的掙值管理和更高層次的項目監控。如果沒有完善的WBS分解，我們就很難做到這一步，我們的整個項目管理執行過程中的產出就是凌亂的，沒有一個主線串起來。感興趣的可以再去翻看下PMBOK各個過程域中各個過程組的IPPO，可以發現很多過程的輸入都有WBS，足以見WBS在整個項目管理中的基礎和核心作用。　　在這個圖中還強調了下在CMMI三級中我們強調的生命周期模型定義＆過程裁剪，在組織級我們可以根據項目的不同特點將項目進行分類制定不同的項目生命周期模板，這樣在有實際的項目來的時候，只需要根據項目的特點對模板內容進行自定義和裁剪，輸入具體的需求項，即可以自動產生相應的WBS。(該點后續單獨在發文闡述)，這樣自動生成的WBS不僅僅實現了后續的主線跟蹤，還實現了我們在CMMI二級中需要的需求追蹤。一流軟件領導的10個特征　　特征一：敢于設想　　他們是在不確定性上發展起來的技術空想家。　　軟件領導者們必須生活于剃刀邊緣。1987年，在驅車沿法蘭克福到沃爾多夫從一家IBM代理商那兒回家時