軟件工程項(xiàng)目管理思考及探索

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

2、繁瑣的業(yè)務(wù) 一旦用戶增多，性能就變得非常差 交付的產(chǎn)品存在隱患，公司“釣魚”，故意留下漏洞 ......,公司拖拉，項(xiàng)目進(jìn)度緩慢，而且總有各種托辭的借口與理由,案例：教務(wù)處排課系統(tǒng)缺陷四六級報(bào)名系統(tǒng)缺陷......,公司研發(fā)人員態(tài)度差，難于溝通 出現(xiàn)問題時，互相扯皮 ......,6,“軟件危機(jī)”現(xiàn)象,危害嚴(yán)重,典型表現(xiàn),倫敦地鐵，司機(jī)沒上車，地鐵就駛離站臺 丹佛機(jī)場行李系統(tǒng)，延期16個月，成本超出32億美元 Ari

3、ane5，40秒爆炸，損失50億美元 ......,程序質(zhì)量低下 錯誤頻出 進(jìn)度延誤 費(fèi)用劇增 ......,軟件危機(jī),泛指在計(jì)算機(jī)軟件的開發(fā)和維護(hù)過程中所遇到的一系列嚴(yán)重問題。,軟件危機(jī)不可避免，也沒有根治的途徑,要解決軟件危機(jī)，需進(jìn)行系統(tǒng)性的研究,項(xiàng)目建設(shè)，“知己知彼，百戰(zhàn)不殆”,7,利器 ——《軟件工程》,《軟件工程（Software Engineering，SE）》—— 一門集計(jì)算機(jī)科學(xué)、數(shù)學(xué)、邏輯學(xué)及管理學(xué)為一體的學(xué)

4、科，意在通過借鑒傳統(tǒng)工程的原則、方法，來進(jìn)行軟件開發(fā)的管理，從而提高軟件質(zhì)量、降低軟件成本和改進(jìn)軟件性能。,8,軟件工程,學(xué)科發(fā)展概述 學(xué)科知識體系 學(xué)科框架,9,《軟件工程》發(fā)展概述,誕生,定義,軟件工程就是采用工程的概念、原理、技術(shù)和方法來開發(fā)與維護(hù)軟件，把經(jīng)過時間考驗(yàn)而證明正確的管理方法和先進(jìn)軟件技術(shù)結(jié)合起來，運(yùn)用到軟件開發(fā)和維護(hù)過程中，來解決軟件危機(jī)。,思想,以系統(tǒng)性的、規(guī)范化的、可定量的過程化方法去開發(fā)和維護(hù)軟件 使用經(jīng)

5、過時間考驗(yàn)而證明正確的管理技術(shù),1968年，北大西洋公約組織（NATO）舉辦了軟件工程學(xué)術(shù)會議，首次提出,10,《軟件工程》知識體系,含10個知識域，8個學(xué)科,由軟件工程協(xié)調(diào)委員會(SWECC)于2008年確立的版本。,,,,,,11,軟件工程框架,過程：生產(chǎn)目標(biāo)產(chǎn)品所需要的步驟,目標(biāo)：生產(chǎn)具有正確性、可用性以及開銷合宜的軟件產(chǎn)品,軟件工程過程主要包括開發(fā)過程、運(yùn)作過程、維護(hù)過程。 軟件工程過程覆蓋了需求分析、設(shè)計(jì)、實(shí)現(xiàn)、確認(rèn)以及維護(hù)

6、等活動。,正確性——滿足用戶的各項(xiàng)功能需求 可用性——軟件及其使用文檔方便為用戶使用 開銷合宜——軟件開發(fā)及運(yùn)行的各項(xiàng)開銷能夠被用戶接受,軟件工程框架可概括為：目標(biāo)、過程和原則。,原則：圍繞工程設(shè)計(jì)、工程支持以及工程管理在軟件開發(fā)過程中必須遵循的原則。,12,軟件工程的“四項(xiàng)基本原則”,原則三：提供高質(zhì)量的工程支持。,原則二：采用合適的設(shè)計(jì)方法。,“工欲善其事，必先利其器”。軟件工具與環(huán)境對軟件過程的支持頗為重要。,軟件設(shè)計(jì)中，通常

7、要考慮軟件的模塊化、抽象與信息隱蔽、局部化、一致性以及適應(yīng)性等特征,原則一：選取適宜的開發(fā)范型。,原則四：重視軟件開發(fā)過程的管理。,軟件需求、硬件需求以及其他因素之間是相互制約、相互影響的，經(jīng)常需要權(quán)衡。必須認(rèn)識需求定義的易變性，采用適宜的開發(fā)范型予以控制。,軟件工程的管理，直接影響可用資源的有效利用，生產(chǎn)滿足目標(biāo)的軟件產(chǎn)品，提高軟件組織的生產(chǎn)能力等問題。因此，僅當(dāng)軟件過程得以有效管理時，才能實(shí)現(xiàn)有效的軟件工程。,13,軟件生命周期,軟

8、件生命周期(Systems Development Life Cycle，SDLC),問題的定義及規(guī)劃 需求分析 軟件設(shè)計(jì) 程序編碼 軟件測試 運(yùn)行維護(hù),六個階段,14,軟件項(xiàng)目開發(fā)及管理全過程,15,軟件項(xiàng)目管理流程,立項(xiàng)階段,項(xiàng)目驗(yàn)收階段,判斷驗(yàn)收時機(jī)已經(jīng)成熟 驗(yàn)收流程的優(yōu)化后續(xù)服務(wù)及維護(hù)條款,項(xiàng)目執(zhí)行階段,經(jīng)驗(yàn)總結(jié)階段,制定項(xiàng)目建議書、可行性分析、產(chǎn)品調(diào)研、承包商選擇技巧 招投標(biāo)方式 合同上關(guān)于風(fēng)險(xiǎn)應(yīng)對及責(zé)任

9、明晰等內(nèi)容制定,工作計(jì)劃 質(zhì)量監(jiān)管、測試方案 進(jìn)度監(jiān)管,16,軟件項(xiàng)目管理,,項(xiàng)目管理復(fù)雜性分析 軟件開發(fā)過程模型概述 軟件項(xiàng)目管理流程 各階段需要注意的事項(xiàng),17,軟件項(xiàng)目管理的復(fù)雜之處,軟件產(chǎn)品是智力產(chǎn)品，軟件項(xiàng)目是設(shè)計(jì)型項(xiàng)目 “隔行如隔山” 軟件使用方在提業(yè)務(wù)需求時往往不能足夠重視 需求變化頻繁，變更難以控制 難以估算工作量 開發(fā)進(jìn)度難以界定 交付成果難以明確 對開發(fā)人員依賴性大 承建商主要目的是利

10、潤，只想提供最少的功能、一定的質(zhì)量，并在合理時間內(nèi)完成 為達(dá)到更高利潤，承建商可能對項(xiàng)目進(jìn)行二次外包，管理更混亂 ……,18,軟件開發(fā)過程,重視軟件開發(fā)過程,過程決定了軟件建設(shè)的步驟與我們管理的方式 過程直接影響最終產(chǎn)品的質(zhì)量,軟件開發(fā)過程模型,瀑布模型 快速原型模型 增量模型 構(gòu)件組裝模型 螺旋模型,19,軟件過程模型——瀑布模型(Waterfall-model),思想,軟件開發(fā)劃分階段 各階段順序執(zhí)行,特征,最早的

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

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

13、反饋不斷調(diào)整，最終確定產(chǎn)品,優(yōu)點(diǎn),開發(fā)方可快速對需求有明晰認(rèn)識 能有效應(yīng)對需求變化，降低風(fēng)險(xiǎn),缺點(diǎn),快速建立起來的原型系統(tǒng)可能架構(gòu)脆弱，不斷修改，導(dǎo)致產(chǎn)品低下,—— 建立快速原型的主要目的是快速獲取與驗(yàn)證需求！,22,軟件過程模型——基于組件的開發(fā)模型,思想：軟件復(fù)用,23,軟件過程模型——螺旋模型(Spiral Model),思想,施工前先進(jìn)行風(fēng)險(xiǎn)評估，通過后快速開發(fā)出原型，交由用戶評估 沿螺旋線自內(nèi)向外每旋轉(zhuǎn)一圈，意味著開發(fā)出更

14、加完善的版本,特征,瀑布模型和快速原型模型的聯(lián)合體 適用于大型復(fù)雜項(xiàng)目，有效控制風(fēng)險(xiǎn),—— 由 Boehm于1988年提出,缺點(diǎn),需要較高的風(fēng)險(xiǎn)評估技術(shù) 風(fēng)險(xiǎn)分析費(fèi)用高，增加成本 應(yīng)用較復(fù)雜,24,軟件過程模型使用總結(jié),需求明確——瀑布模型； 用戶無信息系統(tǒng)使用經(jīng)驗(yàn)，需求分析人員技能不足 —— 快速原型模型 需求不確定因素多，無法提前計(jì)劃 —— 采用增量迭代和螺旋模型 資金和成本無法一次到位 —— 增量模型，軟件產(chǎn)品分多個版

15、本進(jìn)行發(fā)行 全新系統(tǒng)的開發(fā) —— 必須在總體設(shè)計(jì)完成后再開始增量或并行 編碼人員經(jīng)驗(yàn)較少 —— 建議不要采用敏捷或迭代等生命周期模型 增量,迭代和原型可以綜合使用,但每一次增量或迭代都必須有明確的交付和出口準(zhǔn)則,25,“哪種過程模型更好用？”,比較,瀑布模型最簡單，但抗需求變化能力最弱 增量模型分模塊開發(fā)，子系統(tǒng)集成怕不兼容 快速原型模型能最快實(shí)現(xiàn)需求一致性 螺旋模型一般只有大型公司或大型項(xiàng)目采用,不要太在乎學(xué)術(shù)上的“先進(jìn)”

16、與“落后”，適用的就最好。,瀑布模型 增量模型 快速原型模型 螺旋模型,我們最常見的系統(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)目驗(yàn)收階段,判斷驗(yàn)收時機(jī)已經(jīng)成熟 驗(yàn)收流程的優(yōu)化后

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

18、行性分析,立項(xiàng)階段,需求分析。項(xiàng)目的背景、項(xiàng)目的目標(biāo)、業(yè)務(wù)需求、概要設(shè)計(jì)。 技術(shù)可行性分析。 經(jīng)濟(jì)可行性分析。我們預(yù)算多少，硬件方面需要多少投資。 主要風(fēng)險(xiǎn)分析。 人員配置及項(xiàng)目實(shí)施計(jì)劃。 可行性研究的結(jié)論和建議。 其他重要意見。,30,立項(xiàng)階段,需求的基本標(biāo)準(zhǔn),需求管理的誤區(qū),開發(fā)分析階段，開發(fā)方與客戶只需要在輪廓上達(dá)成基本一致即可，具體細(xì)節(jié)以后再填充。 軟件項(xiàng)目需求可以持續(xù)不斷地改變?！獙?shí)踐表明，隨著開發(fā)進(jìn)度的推進(jìn)，

19、實(shí)現(xiàn)軟件需求更改所需的代價呈指數(shù)形式增長。 僅僅滿足目前需求即可，不考慮未來幾年的狀況。,準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍,完整、正確 可行、必要 劃分優(yōu)先級 無二義性、可驗(yàn)證,堅(jiān)持需求的審查,對部分重要需求進(jìn)行追蹤,31,立項(xiàng)階段,技術(shù) ——開發(fā)能力如何？技術(shù)方案是否滿意？ 管理 ——內(nèi)部組織是否混亂？ 進(jìn)度—— 開發(fā)進(jìn)度是否可以接受？ 經(jīng)驗(yàn)—— 是否有相關(guān)領(lǐng)域、相似產(chǎn)品的開發(fā)經(jīng)驗(yàn)、以前開發(fā)的產(chǎn)品質(zhì)量如何？ 誠信度 ——信譽(yù)、

20、口碑如何？采用“一票否決制” 資質(zhì)——是否取得業(yè)界認(rèn)可證書（如ISO9000質(zhì)量認(rèn)證、CMM認(rèn)證），證書等級后續(xù)服務(wù)——能否提供較好的開發(fā)及維護(hù)服務(wù) 經(jīng)濟(jì)實(shí)用性——性價比如何？ 其他因素——比如地理位置等,選擇軟件供應(yīng)商考慮因素,CMM五個等級,32,第四步：合同簽署，明晰管理章程。,立項(xiàng)階段,第三步：專家組評審《可行性分析報(bào)告》,專門的技術(shù)人員、軟件最終使用者涉及到的相關(guān)利益主體。案例：教務(wù)處排課系統(tǒng)對多媒體教室管理帶來的影

21、響。,不僅僅是形式，啟動是為了形成一個良好的溝通體系，讓所有項(xiàng)目人員都理解項(xiàng)目重要性，同時明晰職責(zé)，保障項(xiàng)目管理的暢通。,第五步：項(xiàng)目啟動儀式——“磨刀不誤砍柴工”。,考慮到后續(xù)開發(fā)過程中進(jìn)度、質(zhì)量等方面的干擾因素，制定規(guī)章條例。 盡可能提前預(yù)估風(fēng)險(xiǎn)，制定應(yīng)對方案。,33,項(xiàng)目策劃階段,工作量估計(jì)。 尋找關(guān)鍵路徑。通過定義各任務(wù)之間的依賴關(guān)系，計(jì)算出項(xiàng)目中的關(guān)鍵路徑，幫助區(qū)分任務(wù)的輕重緩急，合理安排和調(diào)整資源，從而保證項(xiàng)目的整體進(jìn)度

22、。,軟件項(xiàng)目主管的任務(wù)——“排兵布陣”,37,目標(biāo)：進(jìn)度快、投資省、質(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ù),進(jìn)度、成本、質(zhì)量、風(fēng)險(xiǎn)、人力資源等等。,進(jìn)度、成本、質(zhì)量——對立統(tǒng)一關(guān)系,成本除了資金成本，還有人力成本，資金少，就多付出些汗水。,38,項(xiàng)目執(zhí)

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

24、而延遲 意外發(fā)生(比如停電、開發(fā)人員生病等) 使用方需求變更,主觀原因,開發(fā)人員沒有全神貫注于自己的工作。 開發(fā)人員不恰當(dāng)?shù)墓ぷ鞣绞健?任務(wù)定義依賴性強(qiáng)，人員工作之間扯皮。 項(xiàng)目經(jīng)理過多干預(yù)開發(fā)人員工作。,應(yīng)對措施,——重新定義進(jìn)度計(jì)劃——重新定義任務(wù)，舍棄過難技術(shù)問題——萬不可為了趕進(jìn)度而降低測試標(biāo)準(zhǔn)！——按風(fēng)險(xiǎn)管理中制定的應(yīng)急措施處理——核心/關(guān)鍵功能的里程碑事件定義,應(yīng)對措施,——生活原因？多多溝通、績效考核—

25、—有針對性地進(jìn)行經(jīng)驗(yàn)交流和培訓(xùn)——依賴性強(qiáng)的任務(wù)合并！——“用人不疑、疑人不用”,項(xiàng)目執(zhí)行階段——進(jìn)度管理(4),43,技巧,延遲如果不補(bǔ)救，就會呈加速度擴(kuò)展。 如果沒有很好的辦法，那就辛苦一點(diǎn)，最笨的辦法是“緊盯”。 “防患于未然”，影響進(jìn)度的許多因素，我們爭取在立項(xiàng)時就要充分考慮到。,項(xiàng)目執(zhí)行階段——質(zhì)量管理(1),44,軟件質(zhì)量度量因素,正確性——精確地滿足需求的程度 健壯性——容錯能力，恢復(fù)能力 可靠性——誤差累

26、積、代碼缺陷，突然不正常 性能——“時間-空間”效率，速度快、占用資源少 易用性——用戶友好性 清晰性——使用文檔詳實(shí)、易懂 可擴(kuò)展性——適應(yīng)變化的能力，模塊化功能改進(jìn),項(xiàng)目執(zhí)行階段——質(zhì)量管理(2),45,棘手的問題,大多數(shù)公司不認(rèn)真關(guān)注質(zhì)量，只想盡快通過“驗(yàn)收”。 “釣魚”現(xiàn)象存在。,如何保證質(zhì)量？——3大原則,缺陷預(yù)防?！傲闳毕莨芾怼保百|(zhì)量是做出來的，不是測出來的”。 重在過程。每個階段都要嚴(yán)格組織，責(zé)任到人

27、，多層把關(guān)。 嚴(yán)格審查?！皽y試驅(qū)動開發(fā)”，并發(fā)數(shù)，壓力測試等等。,作為甲方，我們需要注意,分階段質(zhì)量把控 驗(yàn)收時結(jié)合業(yè)務(wù)進(jìn)行多種手段的測試。 “試行期”要盡量發(fā)現(xiàn)更多問題。,項(xiàng)目驗(yàn)收階段(1),46,驗(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)工作完成。,驗(yàn)收內(nèi)容,功能檢測。 質(zhì)量鑒

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

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

30、要及早預(yù)期多參照相關(guān)利益人征集項(xiàng)目建設(shè)意見,選取合適的項(xiàng)目建設(shè)方式,立項(xiàng)階段(2),52,考量軟件承包商或開發(fā)團(tuán)隊(duì)所關(guān)注的因素,,盡量考慮開發(fā)過程中進(jìn)度、質(zhì)量等方面的干擾因素，制定規(guī)章條例盡可能提前預(yù)估風(fēng)險(xiǎn)，制定應(yīng)對方案。,合同簽署，明晰管理章程,技術(shù)、管理、進(jìn)度、 經(jīng)驗(yàn)、誠信度、資質(zhì)、 后續(xù)服務(wù)、經(jīng)濟(jì)實(shí)用性其他因素,項(xiàng)目啟動儀式——建立良好的溝通渠道,項(xiàng)目建設(shè)階段(1),53,詳實(shí)準(zhǔn)確的需求分析,盡可能準(zhǔn)確界定系統(tǒng)的目標(biāo)和范圍,

31、標(biāo)準(zhǔn)：完整、正確、可行、必要、劃分優(yōu)先級、無二義性、可驗(yàn)證發(fā)現(xiàn)問題及時溝通，堅(jiān)持需求審查對部分重要需求制定跟蹤,加強(qiáng)溝通,結(jié)合自身的專業(yè)技術(shù)知識與開發(fā)人員多加強(qiáng)交流溝通 互相學(xué)習(xí),項(xiàng)目建設(shè)階段(2),54,進(jìn)度管理,質(zhì)量管理,可能影響進(jìn)度的風(fēng)險(xiǎn)因素要在立項(xiàng)時就盡可能考慮到，規(guī)定解決方案項(xiàng)目實(shí)施過程中，從專業(yè)技術(shù)的角度，借助于里程碑等方法，盡可能詳實(shí)地去把握項(xiàng)目進(jìn)度進(jìn)度出現(xiàn)延遲時，要認(rèn)真分析相應(yīng)的主客觀原因，對癥下藥,“質(zhì)量是

32、做出來的，不是測出來的”，要加強(qiáng)質(zhì)量缺陷預(yù)防 重在過程管理，各階段進(jìn)行嚴(yán)格審查 設(shè)定軟件“試行期”，通過實(shí)踐檢驗(yàn)發(fā)現(xiàn)質(zhì)量問題 從專業(yè)技術(shù)角度分析可能存在的質(zhì)量隱患，盡量避免“公司釣魚”,項(xiàng)目驗(yàn)收階段,55,認(rèn)真調(diào)研，準(zhǔn)確判斷驗(yàn)收時機(jī)是否成熟,驗(yàn)收流程的優(yōu)化,是否已經(jīng)滿足了合同要求的全部內(nèi)容 是否進(jìn)行了認(rèn)真的白盒、黑盒測試，發(fā)現(xiàn)的問題是否已全部解決 軟件安裝和部署是否運(yùn)行完成，運(yùn)行穩(wěn)定 相關(guān)使用人員的培訓(xùn)工作已經(jīng)完成,內(nèi)部先擬

33、定比較詳實(shí)的驗(yàn)收方案 初步驗(yàn)收、復(fù)審驗(yàn)收,驗(yàn)收內(nèi)容,軟件功能、性能、質(zhì)量是否達(dá)標(biāo) 操作文檔、部署資料是否齊全,后續(xù)服務(wù)的一些洽談,56,項(xiàng)目總結(jié)階段,問題跟蹤情況總結(jié) 突發(fā)事件應(yīng)對情況的總結(jié),從經(jīng)驗(yàn)中學(xué)習(xí),經(jīng)驗(yàn)教訓(xùn)匯總 實(shí)事求是 不回避、隱瞞問題和矛盾,認(rèn)真回顧項(xiàng)目的實(shí)施過程,召開項(xiàng)目總結(jié)交流會,57,報(bào)告內(nèi)容總結(jié),軟件危機(jī) VS 軟件工程軟件開發(fā)過程軟件項(xiàng)目管理昆工軟件項(xiàng)目管理方案,感謝各位老師！懇請不吝指正！,