軟件工程項(xiàng)目管理思考及探索_第1頁
軟件工程項(xiàng)目管理思考及探索_第2頁
軟件工程項(xiàng)目管理思考及探索_第3頁
軟件工程項(xiàng)目管理思考及探索_第4頁
已閱讀5頁,還剩53頁未讀, 繼續(xù)免費(fèi)閱讀

下載本文檔

版權(quán)說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權(quán),請進(jìn)行舉報或認(rèn)領(lǐng)

文檔簡介

1、軟件工程項(xiàng)目管理思考及探索軟件工程項(xiàng)目管理思考及探索主講人:主講人:馮旭鵬部部 門:門:信息技術(shù)科日日 期:期:2013.10.31主要內(nèi)容主要內(nèi)容 引言引言 軟件工程軟件工程 軟件項(xiàng)目管理軟件項(xiàng)目管理 昆工軟件項(xiàng)目管理思考昆工軟件項(xiàng)目管理思考 內(nèi)容總結(jié)內(nèi)容總結(jié)23引言引言 工作中遇到的問題工作中遇到的問題 “軟件危機(jī)軟件危機(jī)”現(xiàn)象現(xiàn)象軟件工程軟件工程4工作概述工作概述 建設(shè)“校園信息化”信息資源管理平臺 建設(shè)和完善重點(diǎn)應(yīng)用系統(tǒng) .5我們所遇到的共性問題我們所遇到的共性問題 產(chǎn)品質(zhì)量問題產(chǎn)品質(zhì)量問題 項(xiàng)目進(jìn)度問題項(xiàng)目進(jìn)度問題 產(chǎn)品與要求相差甚遠(yuǎn) 沒有提高工作效率,反而增加了繁瑣的業(yè)務(wù) 一旦用戶

2、增多,性能就變得非常差 交付的產(chǎn)品存在隱患,公司“釣魚”,故意留下漏洞 . 公司拖拉,項(xiàng)目進(jìn)度緩慢,而且總有各種托辭的借口與理由案例案例:教務(wù)處排課系統(tǒng)缺陷四六級報名系統(tǒng)缺陷. 公司研發(fā)人員態(tài)度差,難于溝通 出現(xiàn)問題時,互相扯皮 .6“軟件危機(jī)軟件危機(jī)”現(xiàn)象現(xiàn)象 危害嚴(yán)重危害嚴(yán)重 典型表現(xiàn)典型表現(xiàn) 倫敦地鐵,司機(jī)沒上車,地鐵就駛離站臺 丹佛機(jī)場行李系統(tǒng),延期16個月,成本超出32億美元 Ariane5,40秒爆炸,損失50億美元 . 程序質(zhì)量低下 錯誤頻出 進(jìn)度延誤 費(fèi)用劇增 . 軟件危機(jī)軟件危機(jī) 泛指在計算機(jī)軟件的開發(fā)和維護(hù)過程中開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題一系列嚴(yán)重問題。 軟件軟

3、件危機(jī)不可避免,也沒有根治的途徑危機(jī)不可避免,也沒有根治的途徑 要解決軟件危機(jī),需進(jìn)行系統(tǒng)性的研究要解決軟件危機(jī),需進(jìn)行系統(tǒng)性的研究 項(xiàng)目建設(shè),項(xiàng)目建設(shè),“知己知彼,百戰(zhàn)不殆知己知彼,百戰(zhàn)不殆”7利器利器 軟件工程軟件工程 軟件工程(Software Engineering,SE) 一門集計算機(jī)科學(xué)、數(shù)學(xué)、邏輯學(xué)及管理學(xué)為一體的學(xué)科,意在通過借鑒傳統(tǒng)工程的原則、方法,來進(jìn)行軟件開發(fā)的管理,從而提高軟件質(zhì)量、降低軟件成本和改進(jìn)軟件性能。8軟件工程軟件工程 學(xué)科發(fā)展概述學(xué)科發(fā)展概述 學(xué)科知識體系學(xué)科知識體系 學(xué)科框架學(xué)科框架9軟件工程發(fā)展概述軟件工程發(fā)展概述 誕生誕生 定義定義 軟件工程就是軟件工

4、程就是采用工程的概念、原理、技術(shù)和方法采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟來開發(fā)與維護(hù)軟件,把經(jīng)過時間考驗(yàn)而證明正確的件,把經(jīng)過時間考驗(yàn)而證明正確的管理方法和先進(jìn)軟件技術(shù)管理方法和先進(jìn)軟件技術(shù)結(jié)合起來,結(jié)合起來,運(yùn)用到軟件開發(fā)和維護(hù)過程中,來運(yùn)用到軟件開發(fā)和維護(hù)過程中,來解決軟件危機(jī)解決軟件危機(jī)。 思想思想 以系統(tǒng)性的、規(guī)范化的、可定量的過程化方法去開發(fā)和維護(hù)軟件 使用經(jīng)過時間考驗(yàn)而證明正確的管理技術(shù) 1968年,北大西洋公約組織(NATO)舉辦了軟件工程學(xué)術(shù)會議,首次提出10軟件工程知識體系軟件工程知識體系含10個知識域,8個學(xué)科由軟件工程協(xié)調(diào)委員會(SWECC)于2008年確立的

5、版本。11 軟件工程框架軟件工程框架 過程過程:生產(chǎn)目標(biāo)產(chǎn)品所需要的步驟:生產(chǎn)目標(biāo)產(chǎn)品所需要的步驟 目標(biāo)目標(biāo):生產(chǎn)具有正確性、可用性以及開銷合宜的軟件產(chǎn)品:生產(chǎn)具有正確性、可用性以及開銷合宜的軟件產(chǎn)品 軟件工程過程主要包括開發(fā)過程、運(yùn)作過程、維護(hù)過程。 軟件工程過程覆蓋了需求分析、設(shè)計、實(shí)現(xiàn)、確認(rèn)以及維護(hù)等活動。 正確性滿足用戶的各項(xiàng)功能需求 可用性軟件及其使用文檔方便為用戶使用 開銷合宜軟件開發(fā)及運(yùn)行的各項(xiàng)開銷能夠被用戶接受 軟件工程框架可概括為:軟件工程框架可概括為:目標(biāo)、過程目標(biāo)、過程和和原則原則。 原則原則:圍繞工程設(shè)計、工程支持以及工程管理在軟件開發(fā):圍繞工程設(shè)計、工程支持以及工程管

6、理在軟件開發(fā)過程中必須遵循的原則。過程中必須遵循的原則。12 軟件工程的軟件工程的“四項(xiàng)基本原則四項(xiàng)基本原則” 原則三:提供高質(zhì)量的工程支持。原則三:提供高質(zhì)量的工程支持。 原則二:采用合適的設(shè)計方法。原則二:采用合適的設(shè)計方法。 “工欲善其事,必先利其器”。軟件工具與環(huán)境對軟件過程的支持頗為重要。 軟件設(shè)計中,通常要考慮軟件的模塊化、抽象與信息隱蔽、局部化、一致性以及適應(yīng)性等特征 原則一:選取適宜的開發(fā)范型。原則一:選取適宜的開發(fā)范型。 軟件需求、硬件需求以及其他因素之間是相互制約、相互影響的,經(jīng)常需要權(quán)衡。必須認(rèn)識需求定義的易變性必須認(rèn)識需求定義的易變性,采用適宜的開發(fā)范型予以控制。 軟件

7、工程的管理,直接影響可用資源的有效利用,生產(chǎn)滿足目標(biāo)的軟件產(chǎn)品,提高軟件組織的生產(chǎn)能力等問題。因此,僅當(dāng)軟件過程得以有效管理時,才能實(shí)現(xiàn)有效的軟件工程。13 軟件生命周期軟件生命周期軟件生命周期軟件生命周期(Systems Development Life Cycle,SDLC) 問題的定義及規(guī)劃 需求分析 軟件設(shè)計 程序編碼 軟件測試 運(yùn)行維護(hù)六個階段六個階段14軟件項(xiàng)目開發(fā)及管理全過程軟件項(xiàng)目開發(fā)及管理全過程15軟件項(xiàng)目管理流程軟件項(xiàng)目管理流程 立項(xiàng)階段立項(xiàng)階段 項(xiàng)目驗(yàn)收階段項(xiàng)目驗(yàn)收階段 判斷驗(yàn)收時機(jī)已經(jīng)成熟 驗(yàn)收流程的優(yōu)化后續(xù)服務(wù)及維護(hù)條款 項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段 經(jīng)驗(yàn)總結(jié)階段經(jīng)驗(yàn)總結(jié)

8、階段 制定項(xiàng)目建議書、可行性分析、產(chǎn)品調(diào)研、承包商選擇技巧 招投標(biāo)方式 合同上關(guān)于風(fēng)險應(yīng)對及責(zé)任明晰等內(nèi)容制定 工作計劃 質(zhì)量監(jiān)管、測試方案 進(jìn)度監(jiān)管16軟件項(xiàng)目管理軟件項(xiàng)目管理 項(xiàng)目管理復(fù)雜性分析項(xiàng)目管理復(fù)雜性分析 軟件開發(fā)過程模型概述軟件開發(fā)過程模型概述 軟件項(xiàng)目管理流程軟件項(xiàng)目管理流程 各階段需要注意的事項(xiàng)各階段需要注意的事項(xiàng)17軟件項(xiàng)目管理的復(fù)雜之處軟件項(xiàng)目管理的復(fù)雜之處 軟件產(chǎn)品是智力產(chǎn)品,軟件項(xiàng)目是設(shè)計型項(xiàng)目軟件產(chǎn)品是智力產(chǎn)品,軟件項(xiàng)目是設(shè)計型項(xiàng)目 “隔行如隔山隔行如隔山” 軟件使用方在提業(yè)務(wù)需求時往往不能足夠重視軟件使用方在提業(yè)務(wù)需求時往往不能足夠重視 需求變化頻繁,變更難以控制

9、需求變化頻繁,變更難以控制 難以估算工作量難以估算工作量 開發(fā)進(jìn)度難以界定開發(fā)進(jìn)度難以界定 交付成果交付成果難以難以明確明確 對開發(fā)人員依賴性大對開發(fā)人員依賴性大 承建商主要目的是利潤,只想提供最少的功能、一定的質(zhì)量,并在合理時間內(nèi)完成承建商主要目的是利潤,只想提供最少的功能、一定的質(zhì)量,并在合理時間內(nèi)完成 為達(dá)到更高利潤,承建商可能對項(xiàng)目進(jìn)行二次外包,管理更混亂為達(dá)到更高利潤,承建商可能對項(xiàng)目進(jìn)行二次外包,管理更混亂 18軟件開發(fā)過程軟件開發(fā)過程 重視軟件開發(fā)過程重視軟件開發(fā)過程 過程決定了軟件建設(shè)的步驟與我們管理的方式 過程直接影響最終產(chǎn)品的質(zhì)量 軟件開發(fā)過程模型軟件開發(fā)過程模型 瀑布模型

10、 快速原型模型 增量模型 構(gòu)件組裝模型 螺旋模型19軟件過程模型軟件過程模型瀑布模型瀑布模型( (Waterfall-model) ) 思想思想 軟件開發(fā)劃分階段 各階段順序執(zhí)行 特征特征 最早的、最簡單的模型 “理想化”的順序模型 單向性,工作不可逆轉(zhuǎn) 優(yōu)點(diǎn)優(yōu)點(diǎn) 為項(xiàng)目提供分階段的檢查點(diǎn)當(dāng)前活動完成,只需關(guān)注后續(xù)活動 模板清晰 缺點(diǎn)缺點(diǎn) 抵抗“需求不斷變化”能力弱。 用戶最終才能見產(chǎn)品,增加開發(fā)風(fēng)險。 開發(fā)人員常常陷入“阻塞狀態(tài)” 各階段劃分完全固定,產(chǎn)生大量文檔,增加工作量。 由 Royce 于1970年提出20軟件過程模型軟件過程模型增量模型增量模型( (incremental mode

11、l) ) 思想思想 功能拆分,每個子功能按瀑布模型開發(fā) 最終合并所有“增量” 特征特征 分模塊開發(fā) 多段瀑布模型 優(yōu)點(diǎn)優(yōu)點(diǎn) 抗變化能力比瀑布模型強(qiáng) 可以邊開發(fā),邊應(yīng)用 缺點(diǎn)缺點(diǎn) 所有子系統(tǒng)合并可能“不兼容” 對系統(tǒng)設(shè)計師的水平要求高舉例:字處理軟件解決方法:面向接口的編程方法解決方法:面向接口的編程方法適用于:小型或是交互型式的系統(tǒng)。大型系統(tǒng)的某些部分,例如用戶界面。21軟件過程模型軟件過程模型快速原型模型快速原型模型( (rapid prototype) ) 思想思想 根據(jù)需求先較小代價、快速構(gòu)建一個軟件的“雛形” 根據(jù)用戶反饋不斷調(diào)整,最終確定產(chǎn)品 優(yōu)點(diǎn)優(yōu)點(diǎn) 開發(fā)方可快速對需求有明晰認(rèn)識

12、能有效應(yīng)對需求變化,降低風(fēng)險 缺點(diǎn)缺點(diǎn) 快速建立起來的原型系統(tǒng)可能架構(gòu)脆弱,不斷修改,導(dǎo)致產(chǎn)品低下 建立快速原型的主要目的是快速獲取與驗(yàn)證需求!建立快速原型的主要目的是快速獲取與驗(yàn)證需求!22軟件過程模型軟件過程模型基于組件的開發(fā)模型基于組件的開發(fā)模型 思想:軟件復(fù)用思想:軟件復(fù)用 23軟件過程模型軟件過程模型螺旋模型螺旋模型( (Spiral Model) ) 思想思想 施工前先進(jìn)行風(fēng)險評估,通過后快速開發(fā)出原型,交由用戶評估 沿螺旋線自內(nèi)向外每旋轉(zhuǎn)一圈,意味著開發(fā)出更加完善的版本 特征特征 瀑布模型和快速原型模型的聯(lián)合體 適用于大型復(fù)雜項(xiàng)目,有效控制風(fēng)險 由 Boehm于1988年提出 缺

13、點(diǎn)缺點(diǎn) 需要較高的風(fēng)險評估技術(shù) 風(fēng)險分析費(fèi)用高,增加成本 應(yīng)用較復(fù)雜24 軟件過程模型使用總結(jié)軟件過程模型使用總結(jié) 需求明確瀑布模型; 用戶無信息系統(tǒng)使用經(jīng)驗(yàn),需求分析人員技能不足 快速原型模型 需求不確定因素多,無法提前計劃 采用增量迭代和螺旋模型 資金和成本無法一次到位 增量模型,軟件產(chǎn)品分多個版本進(jìn)行發(fā)行 全新系統(tǒng)的開發(fā) 必須在總體設(shè)計完成后再開始增量或并行 編碼人員經(jīng)驗(yàn)較少 建議不要采用敏捷或迭代等生命周期模型 增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則25“哪種過程模型更好用?哪種過程模型更好用?” 比較比較 瀑布模型最簡單,但抗需求變化能力最弱 增

14、量模型分模塊開發(fā),子系統(tǒng)集成怕不兼容 快速原型模型能最快實(shí)現(xiàn)需求一致性 螺旋模型一般只有大型公司或大型項(xiàng)目采用不要太在乎學(xué)術(shù)上的“先進(jìn)”與“落后”,適用的就最好。 瀑布模型 增量模型 快速原型模型 螺旋模型我們最常見的系統(tǒng)都是采用增量模型、快速原型模型來開發(fā)。 當(dāng)前對軟件研發(fā)過程質(zhì)量的評判主要是以SEI(Software Engineering Institute)頒布的CMMI(Capability Maturity Model Integration)作為研發(fā)標(biāo)準(zhǔn)。26軟件項(xiàng)目管理流程軟件項(xiàng)目管理流程 立項(xiàng)階段立項(xiàng)階段 項(xiàng)目驗(yàn)收階段項(xiàng)目驗(yàn)收階段 判斷驗(yàn)收時機(jī)已經(jīng)成熟 驗(yàn)收流程的優(yōu)化后續(xù)服務(wù)

15、及維護(hù)條款 項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段 經(jīng)驗(yàn)總結(jié)階段經(jīng)驗(yàn)總結(jié)階段 制定項(xiàng)目建議書、可行性分析、產(chǎn)品調(diào)研、承包商選擇技巧 招投標(biāo)方式 合同上關(guān)于風(fēng)險應(yīng)對及責(zé)任明晰等內(nèi)容制定 工作計劃 質(zhì)量監(jiān)管、測試方案 進(jìn)度監(jiān)管28立項(xiàng)階段立項(xiàng)階段 方向比努力更重要方向比努力更重要 第一步:項(xiàng)目建議書第一步:項(xiàng)目建議書 項(xiàng)目背景。 意義和必要性。 未來收益預(yù)期。 規(guī)模和期限。 投資估算。 資金籌措。 其他重要意見。提交項(xiàng)目建議書給相關(guān)部門進(jìn)行審核,提交項(xiàng)目建議書給相關(guān)部門進(jìn)行審核,“上會上會”29 第二步:項(xiàng)目可行性分析第二步:項(xiàng)目可行性分析立項(xiàng)階段立項(xiàng)階段 需求分析需求分析。項(xiàng)目的背景、項(xiàng)目的目標(biāo)、業(yè)務(wù)需求、概

16、要設(shè)計。 技術(shù)可行性分析。 經(jīng)濟(jì)可行性分析。我們預(yù)算多少,硬件方面需要多少投資。 主要風(fēng)險分析。 人員配置及項(xiàng)目實(shí)施計劃人員配置及項(xiàng)目實(shí)施計劃。 可行性研究的結(jié)論和建議。 其他重要意見。30立項(xiàng)階段立項(xiàng)階段 需求的基本標(biāo)準(zhǔn)需求的基本標(biāo)準(zhǔn) 需求管理的誤區(qū)需求管理的誤區(qū) 開發(fā)分析階段,開發(fā)方與客戶只需要在輪廓上達(dá)成基本一致即可,具體細(xì)節(jié)以后再填充。 軟件項(xiàng)目需求可以持續(xù)不斷地改變。實(shí)踐表明,隨著開發(fā)進(jìn)度的推進(jìn),實(shí)現(xiàn)軟件需求更改所需的代價呈指數(shù)形式增長。 僅僅滿足目前需求即可,不考慮未來幾年的狀況。u準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍 完整、正確 可行、必要 劃分優(yōu)先級 無二義性、可驗(yàn)

17、證 堅(jiān)持需求的審查堅(jiān)持需求的審查 對部分重要需求進(jìn)行追蹤對部分重要需求進(jìn)行追蹤31立項(xiàng)階段立項(xiàng)階段 技術(shù)技術(shù) 開發(fā)能力如何?技術(shù)方案是否滿意? 管理管理 內(nèi)部組織是否混亂? 進(jìn)度進(jìn)度 開發(fā)進(jìn)度是否可以接受? 經(jīng)驗(yàn)經(jīng)驗(yàn) 是否有相關(guān)領(lǐng)域、相似產(chǎn)品的開發(fā)經(jīng)驗(yàn)、以前開發(fā)的產(chǎn)品質(zhì)量如何? 誠信度誠信度 信譽(yù)、口碑如何?采用“一票否決制” 資質(zhì)資質(zhì)是否取得業(yè)界認(rèn)可證書(如ISO9000質(zhì)量認(rèn)證、CMM認(rèn)證),證書等級后續(xù)服務(wù)后續(xù)服務(wù)能否提供較好的開發(fā)及維護(hù)服務(wù) 經(jīng)濟(jì)實(shí)用性經(jīng)濟(jì)實(shí)用性性價比如何? 其他因素其他因素比如地理位置等 選擇軟件供應(yīng)商考慮因素選擇軟件供應(yīng)商考慮因素CMM五個等級32 第四步:合同簽署

18、,明晰管理章程。第四步:合同簽署,明晰管理章程。立項(xiàng)階段立項(xiàng)階段 第三步:專家組評審第三步:專家組評審可行性分析報告可行性分析報告專門的技術(shù)人員、軟件最終使用者涉及到的相關(guān)利益主體使用者涉及到的相關(guān)利益主體。案例:教務(wù)處排課系統(tǒng)對多媒體教室管理帶來的影響。 不僅僅是形式,啟動是為了形成一個良好的溝通體系,讓所有項(xiàng)目人員都理解項(xiàng)目重要性,同時明晰職責(zé),保障項(xiàng)目管理的暢通。 第五步:項(xiàng)目啟動儀式第五步:項(xiàng)目啟動儀式“磨刀不誤砍柴工磨刀不誤砍柴工”。 考慮到后續(xù)開發(fā)過程中進(jìn)度、質(zhì)量等方面的干擾因素,制定規(guī)章條例。 盡可能提前預(yù)估風(fēng)險,制定應(yīng)對方案。33項(xiàng)目策劃階段項(xiàng)目策劃階段 工作量估計工作量估計。

19、 尋找尋找關(guān)鍵路徑關(guān)鍵路徑。通過定義各任務(wù)之間的依賴關(guān)系,計算出項(xiàng)目中的關(guān)鍵路徑,幫助區(qū)分任務(wù)的輕重緩急,合理安排和調(diào)整資源,從而保證項(xiàng)目的整體進(jìn)度。 軟件項(xiàng)目主管的任務(wù)軟件項(xiàng)目主管的任務(wù)“排兵布陣排兵布陣”37 目標(biāo):進(jìn)度快、投資省、質(zhì)量好。目標(biāo):進(jìn)度快、投資省、質(zhì)量好。項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段 進(jìn)度快就要增加投資,而項(xiàng)目提前使用卻又可能及早提高收益。 進(jìn)度快,質(zhì)量也許就不能保證;質(zhì)量嚴(yán)格控制,則有可能影響進(jìn)度;質(zhì)量嚴(yán)格控制不至返工,又會加快進(jìn)度。 “脫離成本,不談質(zhì)量”。 項(xiàng)目負(fù)責(zé)人的任務(wù)項(xiàng)目負(fù)責(zé)人的任務(wù)進(jìn)度、成本、質(zhì)量、風(fēng)險、人力資源等等。 進(jìn)度、成本、質(zhì)量進(jìn)度、成本、質(zhì)量對立統(tǒng)一對立統(tǒng)

20、一關(guān)系關(guān)系成本除了資金成本,還有人力成本,資金少,就多付出些汗水。38項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段進(jìn)度管理進(jìn)度管理(1)(1)39 進(jìn)度的描述進(jìn)度的描述 里程碑 做完、沒做完,沒有第三種狀態(tài) 甘特圖40甘特圖示例甘特圖示例項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段進(jìn)度管理進(jìn)度管理(2)(2)41 影響進(jìn)度的主要因素影響進(jìn)度的主要因素 錯估了項(xiàng)目特點(diǎn)及實(shí)現(xiàn)條件。 項(xiàng)目參與者工作錯誤。 不可預(yù)見事件發(fā)生。面對進(jìn)度延遲,我們該怎么做呢?分析主客觀原因,對癥下藥!項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段進(jìn)度管理進(jìn)度管理(3)(3)42 客觀原因客觀原因 進(jìn)度計劃不合理,過于理想化等 任務(wù)定義過于復(fù)雜、過度定義、超出范圍 測試太多錯誤而延遲

21、 意外發(fā)生(比如停電、開發(fā)人員生病等) 使用方需求變更 主觀原因主觀原因 開發(fā)人員沒有全神貫注于自己的工作。 開發(fā)人員不恰當(dāng)?shù)墓ぷ鞣绞健?任務(wù)定義依賴性強(qiáng),人員工作之間扯皮。 項(xiàng)目經(jīng)理過多干預(yù)開發(fā)人員工作。 應(yīng)對措施應(yīng)對措施重新定義進(jìn)度計劃重新定義任務(wù),舍棄過難技術(shù)問題萬不可為了趕進(jìn)度而降低測試標(biāo)準(zhǔn)!按風(fēng)險管理中制定的應(yīng)急措施處理核心/關(guān)鍵功能的里程碑事件定義 應(yīng)對措施應(yīng)對措施生活原因?多多溝通、績效考核有針對性地進(jìn)行經(jīng)驗(yàn)交流和培訓(xùn)依賴性強(qiáng)的任務(wù)合并!“用人不疑、疑人不用”項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段進(jìn)度管理進(jìn)度管理(4)(4)43 技巧技巧 延遲如果不補(bǔ)救,就會呈加速度擴(kuò)展。 如果沒有很好的辦法

22、,那就辛苦一點(diǎn),最笨的辦法是“緊盯”。 “防患于未然”,影響進(jìn)度的許多因素,我們爭取在立項(xiàng)時就要充分考慮到。項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段質(zhì)量管理質(zhì)量管理(1)(1)44 軟件質(zhì)量度量因素軟件質(zhì)量度量因素 正確性正確性精確地滿足需求的程度 健壯性健壯性容錯能力,恢復(fù)能力 可靠性可靠性誤差累積、代碼缺陷,突然不正常 性能性能“時間-空間”效率,速度快、占用資源少 易用性易用性用戶友好性 清晰性清晰性使用文檔詳實(shí)、易懂 可擴(kuò)展性可擴(kuò)展性適應(yīng)變化的能力,模塊化功能改進(jìn)項(xiàng)目執(zhí)行階段項(xiàng)目執(zhí)行階段質(zhì)量管理質(zhì)量管理( (2 2) )45 棘手的問題棘手的問題 大多數(shù)公司不認(rèn)真關(guān)注質(zhì)量,只想盡快通過“驗(yàn)收”。 “釣

23、魚”現(xiàn)象存在。 如何保證質(zhì)量?如何保證質(zhì)量?3大原則大原則 缺陷預(yù)防。“零缺陷管理”,“質(zhì)量是做出來的,不是測出來的”。 重在過程。每個階段都要嚴(yán)格組織,責(zé)任到人,多層把關(guān)。 嚴(yán)格審查。“測試驅(qū)動開發(fā)”,并發(fā)數(shù),壓力測試等等。 作為甲方,我們需要注意作為甲方,我們需要注意 分階段質(zhì)量把控 驗(yàn)收時結(jié)合業(yè)務(wù)進(jìn)行多種手段的測試。 “試行期”要盡量發(fā)現(xiàn)更多問題。項(xiàng)目驗(yàn)收階段項(xiàng)目驗(yàn)收階段(1)(1)46 驗(yàn)收前提驗(yàn)收前提 完成合同要求的全部內(nèi)容。 在“試運(yùn)行”期間已完成對軟件系統(tǒng)的嚴(yán)格測試(白盒、黑盒)。 準(zhǔn)備好相關(guān)的開發(fā)文檔和產(chǎn)品文檔。 準(zhǔn)備好軟件安裝和驗(yàn)收的部署環(huán)境。 相關(guān)使用人員的培訓(xùn)工作完成。

24、驗(yàn)收內(nèi)容驗(yàn)收內(nèi)容 功能檢測。 質(zhì)量鑒定。 資料評審。 后續(xù)維護(hù)工作的一些協(xié)商??梢詢?nèi)部先擬定一個詳細(xì)的驗(yàn)收計劃可以內(nèi)部先擬定一個詳細(xì)的驗(yàn)收計劃項(xiàng)目驗(yàn)收階段項(xiàng)目驗(yàn)收階段(2)(2)47 驗(yàn)收流程驗(yàn)收流程 驗(yàn)收報告驗(yàn)收報告 驗(yàn)收小組擬定。 基本情況的各項(xiàng)審核。 一些相關(guān)的合理性建議。 初審。 復(fù)審。項(xiàng)目總結(jié)階段項(xiàng)目總結(jié)階段48 項(xiàng)目實(shí)施過程回顧項(xiàng)目實(shí)施過程回顧 工作或過程的扼要評價 問題的跟蹤情況 變更的管理 突發(fā)事件和突發(fā)沖突的處理 從經(jīng)驗(yàn)中學(xué)習(xí)從經(jīng)驗(yàn)中學(xué)習(xí) 一定要實(shí)事求是! 著眼點(diǎn)要準(zhǔn)確,分析要深入! 不要回避、隱瞞問題和矛盾! 要有主次之分,條理要清晰。項(xiàng)目總結(jié)交流會項(xiàng)目總結(jié)交流會 經(jīng)驗(yàn)教訓(xùn)

25、匯總 棘手難題匯總,如何應(yīng)對展開討論 各抒己見,分享體會 一些改進(jìn)和建議方案的匯總49昆工軟件項(xiàng)目管理思考昆工軟件項(xiàng)目管理思考 昆工軟件項(xiàng)目立項(xiàng)流程圖昆工軟件項(xiàng)目立項(xiàng)流程圖 每個環(huán)節(jié)都注意哪些每個環(huán)節(jié)都注意哪些立項(xiàng)階段立項(xiàng)階段(1)(1)51 成熟產(chǎn)品修改?定制開發(fā)?優(yōu)劣利害對比成熟產(chǎn)品修改?定制開發(fā)?優(yōu)劣利害對比 選擇選擇合適的軟件開發(fā)過程合適的軟件開發(fā)過程l 重視項(xiàng)目的可行性分析重視項(xiàng)目的可行性分析 需求分析格外重要,要盡可能豐富地收集業(yè)務(wù)方的實(shí)際需求需求分析格外重要,要盡可能豐富地收集業(yè)務(wù)方的實(shí)際需求 技術(shù)可行性、經(jīng)濟(jì)可行性等方面要技術(shù)可行性、經(jīng)濟(jì)可行性等方面要客觀客觀考量考量 可能遇到

26、的風(fēng)險問題要及早預(yù)期可能遇到的風(fēng)險問題要及早預(yù)期 多參照相關(guān)利益人征集項(xiàng)目建設(shè)意見多參照相關(guān)利益人征集項(xiàng)目建設(shè)意見u選取合適的項(xiàng)目建設(shè)方式選取合適的項(xiàng)目建設(shè)方式立項(xiàng)階段立項(xiàng)階段(2)(2)52l 考量軟件承包商或開發(fā)團(tuán)隊(duì)所關(guān)注的因素考量軟件承包商或開發(fā)團(tuán)隊(duì)所關(guān)注的因素 盡量考慮開發(fā)過程中進(jìn)度、質(zhì)量等方面的干擾因素,制定規(guī)章條例盡量考慮開發(fā)過程中進(jìn)度、質(zhì)量等方面的干擾因素,制定規(guī)章條例盡可能提前預(yù)估風(fēng)險,制定應(yīng)對方案。盡可能提前預(yù)估風(fēng)險,制定應(yīng)對方案。u合同簽署,明晰管理章程合同簽署,明晰管理章程 技術(shù)、管理、進(jìn)度、技術(shù)、管理、進(jìn)度、 經(jīng)驗(yàn)、誠信度、資質(zhì)、經(jīng)驗(yàn)、誠信度、資質(zhì)、 后續(xù)服務(wù)、經(jīng)濟(jì)實(shí)用性后續(xù)服務(wù)、經(jīng)濟(jì)實(shí)用性 其他因素其他因素l 項(xiàng)目啟動儀式項(xiàng)目啟動儀式建立良好的溝通渠道建立良好的溝通渠道項(xiàng)目建設(shè)階段項(xiàng)目建設(shè)階段(1)(1)53l 詳實(shí)準(zhǔn)確的需求分析詳實(shí)準(zhǔn)確的需求分析u盡可能準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍盡可能準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍 標(biāo)準(zhǔn):完整、正確、可行、必要、劃分優(yōu)先級、無二義性、可驗(yàn)證標(biāo)準(zhǔn):完整、正確、可行、必要、劃分優(yōu)先級、無二義性、可驗(yàn)證 發(fā)現(xiàn)問題及時溝通,堅(jiān)持需求審查發(fā)現(xiàn)問題及時溝通,堅(jiān)持需求審查 對部分重要需求制定跟蹤對部分重要需求制定跟蹤u加強(qiáng)溝通加強(qiáng)溝通 結(jié)合自身的專業(yè)技術(shù)知識與開發(fā)人員多加強(qiáng)交流溝通結(jié)合自身的專業(yè)技術(shù)知

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權(quán)益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預(yù)覽,若沒有圖紙預(yù)覽就沒有圖紙。
  • 4. 未經(jīng)權(quán)益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護(hù)處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負(fù)責(zé)。
  • 6. 下載文件中如有侵權(quán)或不適當(dāng)內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準(zhǔn)確性、安全性和完整性, 同時也不承擔(dān)用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

最新文檔

評論

0/150

提交評論