軟件工程項目管理思考及探索

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

16、與“落后”，適用的就最好。,瀑布模型 增量模型 快速原型模型 螺旋模型,我們最常見的系統(tǒng)都是采用增量模型、快速原型模型來開發(fā)。,當前對軟件研發(fā)過程質(zhì)量的評判主要是以SEI（Software Engineering Institute）頒布的CMMI（Capability Maturity Model Integration）作為研發(fā)標準。,26,軟件項目管理流程,立項階段,項目驗收階段,判斷驗收時機已經(jīng)成熟 驗收流程的優(yōu)化后

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

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

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

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

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

22、。,軟件項目主管的任務(wù)——“排兵布陣”,37,目標：進度快、投資省、質(zhì)量好。,項目執(zhí)行階段,進度快就要增加投資，而項目提前使用卻又可能及早提高收益。 進度快，質(zhì)量也許就不能保證；質(zhì)量嚴格控制，則有可能影響進度；質(zhì)量嚴格控制不至返工，又會加快進度。 “脫離成本，不談質(zhì)量”。,項目負責人的任務(wù),進度、成本、質(zhì)量、風(fēng)險、人力資源等等。,進度、成本、質(zhì)量——對立統(tǒng)一關(guān)系,成本除了資金成本，還有人力成本，資金少，就多付出些汗水。,38,項目執(zhí)

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

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

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

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

27、，多層把關(guān)。 嚴格審查?！皽y試驅(qū)動開發(fā)”，并發(fā)數(shù)，壓力測試等等。,作為甲方，我們需要注意,分階段質(zhì)量把控 驗收時結(jié)合業(yè)務(wù)進行多種手段的測試。 “試行期”要盡量發(fā)現(xiàn)更多問題。,項目驗收階段(1),46,驗收前提,完成合同要求的全部內(nèi)容。 在“試運行”期間已完成對軟件系統(tǒng)的嚴格測試（白盒、黑盒）。 準備好相關(guān)的開發(fā)文檔和產(chǎn)品文檔。 準備好軟件安裝和驗收的部署環(huán)境。 相關(guān)使用人員的培訓(xùn)工作完成。,驗收內(nèi)容,功能檢測。 質(zhì)量鑒

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

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

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

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

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

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