


下載本文檔
版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
1、軟件項目管理在小軟件項目中的應用【摘要】信息技術的飛速開展已是無需爭論的事實,軟件產業的創造的價值也在 逐年增加,在某些國家軟件開發已然成為了支柱產業。 在看到我國軟件開發人員 的不斷成熟,軟件開發環境不斷與國際社會接軌的同時,我們也不能無視我國當 前軟件行業存在的弊端:缺乏統一的行業標準和相應的法律法規, 一些中小型軟 件項目仍然以原始的個人或者小團體為主的手工作坊式的方式進展開發,在大量浪費人力物力的同時也使得程序員辛苦創造的價值在無形之中流失。很多人認為小型軟件項目不需要嚴格的管理,事實上恰恰與此相反,小型軟件項目不單需要 進展項目管理,而且不能完全照搬大型軟件項目的管理方式和開發模式,
2、應該遵循一種適合小型軟件項目的管理方式; 但從另一個角度來看,項目的大與小并沒 有本質的區別,很多方法是共通的。本文的目的是從作者的經驗來談談小項目開 發的管理。【關鍵詞】小軟件項目 項目管理 軟件開發【正文】第一局部軟件項目管理概述1-1軟件項目管理的目的從概念上講,軟件項目管理是為了使軟件項目能夠按照預定的本錢、進度、 質量順利完成,而對本錢、人員、進度、質量、風險等進展分析和管理的活動。 實際上,軟件項目管理的意義不僅僅如此, 進展軟件項目管理有利于將開發人員 的個人開發能力轉化成企業的開發能力, 企業的軟件開發能力越高,明確這個企 業的軟件生產越趨向于成熟,企業越能夠穩定開展即減小開發
3、風險。軟件開發不同于其他產品的制造,軟件的整個過程都是設計過程沒有制造 過程;另外,軟件開發不需要使用大量的物質資源,而主要是人力資源;并且, 軟件開發的產品只是程序代碼和技術文件, 并沒有其他的物質結果。基于上述特 點,軟件項目管理與其他項目管理相比, 有很大的獨特性。項目管理的根本焦點 集中在 T、Q C、S上,即:開發進度The progress of development 、特性 與品質Character and Quality 、本錢Cost、顧客服務Service。其中最核心的是開發進度、特性與品質兩個方面。其它一切管理工作都必須圍繞這些 焦點進展。1-2軟件項目管理的內容從軟件
4、工程的角度講,軟件開發主要分為六個階段:需求分析階段、概要設計階 段、詳細設計階段、編碼階段、測試階段、安裝與維護階段。不論是作坊式開發, 還是團隊協作開發,這六個階段都是不可缺少的。1-3軟件項目管理的原如此在八十年代初,著名軟件工程專家 BW Boehm總結出了軟件開發時需遵 循的七條根本原如此,同樣,我們在進展軟件項目管理時,也應該遵循這七條原 如此。它們是:1用分階段的生命周期計劃嚴格管理;2堅持進展階段評審;3實行嚴格的產品控制;4采用現代程序設計技術;5結果應能夠清楚地審查;6開發小組地人員應該少而精;7承認不斷改良軟件工程實踐地必要性。第二局部 小軟件項目開發2-1小項目的特點本
5、文所說的“小軟件項目是指直接開發人員的數目在 3-10人,軟件開發 的周期在1-5個月之間,代碼數量在 5000-20000行,子程序數量在100-500之 間的小型軟件開發項目。大家知道,“軟件危機的出現起源于一些大型項目的不斷延遲甚至失敗。小項目相比之下,具有以下特點:項目功能相對較少開發人員較少開發周期較短另外,在現實中,有很多小項目的開發人員流動性較大, 這也是不容無視的 一個現實。2-2小項目開發中常犯的錯誤小項目看起來比擬簡單,比擬容易成功,因而人們往往無視了小項目的管理, 其實這是一種誤解,從本人的經驗看來,小項目開發中容易犯以下的一些錯誤:1、開發之前沒有認真地進展項目可行性和
6、工作量的估計。往往由于項目較小,便很草率地制定一個開發日程表, 沒有認真地估計項目難度,結果實際完成 時間與估計完成時間往往有較大差異。2、沒有真正的設計過程開發人員少,意味著不同人員的程序之間交互、 接口相對少一些。開發周期 短意味著往往是同樣的幾個人從頭到尾負責一個項目。這兩者都讓人容易犯些錯 誤。往往是幾個人碰一下頭,討論一下最根本的數據結構、函數接口便分頭去做 自己的工作了,沒有一份較正式的文檔。這種做法潛在的危險之一是有的人可能會對討論出的接口、結構理解有偏差(應該承認人是會犯錯誤的)。一個誤解可能造成以后的返工。另一個潛在的危險是由于討論時忽略了某些情況,等大家都按當時的分工完 成
7、屬于自己的工作后,才發現各個模塊組合起來卻形不成一個完整的系統。其根源在于沒有一個負責協調的人員不斷監控整個開發過程。第三個潛在的危險是一旦有人中途退出開發隊伍,其他人參加時,新來的人難以理解 以前別人做好的代碼,索性自己從頭來。另外,沒有文檔的程序,日 后維護和版本升級都比擬困難。3、不經過單元測試而直接進入系統測試造成這一現象的原因是每個模塊相比照擬簡單,但是為了測試一個模塊需要 建立一些測試環境。例如,為了測試一個函數是否正確,應該用一些測試數據去 調用該函數,需要編寫一些測試數據。但很多開發人員嫌麻煩,覺得反正其他模 塊也很快出來了,直接用真正的數據來運行幾次就行了。殊不知,一旦直接進
8、入系統測試,發現運行結果不正確后需要一步步查找。 由于模塊間的調用關系,可能查了很久才發現是某個模塊的問題。 這種方法一來 效率比擬低,大量的時間用在了將一個錯誤定位在模塊上了。 另外由于這種測試 不完全,真正運行系統,當調用某模塊時,可能大局部時候都是正常數據,極少 出現邊界情況,可能某些邊界情況容易被無視, 很久之后才被發現。但是如果對 每個模塊進展單元測試時都進展一下邊界測試,就會很容易消除一些隱患。真可 謂欲速如此不達也。2-3合理的開發流程合理的開發模式,一句話形容就是“麻雀雖小,五臟俱全,即使是小型項 目的開發,仍然應該遵循軟件開發的一般規律, 必須的步驟不能省略。但是小項 目有它
9、自身的一些特點,實行起來可以相對靈活些。以下我從幾個方面描述一下我認為比擬合理的模式。1、需求獲取在進入正式開發之前,必須先從用戶處獲取準確的需求。 在這上面花費相當 時間是很必要的。軟件項目可以大致分為 專用軟件和通用軟件兩大類。對于專用軟件,例如給某單位開發一套該單位專用的系統, 一般用戶對于軟 件要完成哪些功能已經有了一個比擬清楚的輪廓, 而且往往在開發合同中已經大 致地規定了。但是,開發合同上規定的只是一個大概的框架,在進入開發之前必須與用戶 進展比擬具體的交流和討論,了解清楚用戶心目中的產品終究是什么樣子。 這個 步驟如果沒有好好做,往往到了開發工作的后期才發現開發人員的理解和用戶的
10、 要求有一些誤解,那么必然造成時間上的浪費。對于通用軟件,在開發之前應該做一定的市場調查工作, 一方面是從經濟效 益考慮,調查產品的潛在市場有多大,另一方面是從技術的角度,必須了解清楚 潛在用戶對軟件的各種技術上的要求, 例如,用戶現有硬件配置如何,軟件配置 如何,使用什么網絡,使用什么數據庫等等,根據調查的統計結果斷定即將開發 的軟件的一些技術指標。為了比擬好地與用戶進展交流,使用一些工具是很有好處的。為了討論用戶 界面,可以用VB, delphi等做一個原型,根據原型有針對性地與用戶討論需求。 (原型開發不僅僅可以用于準確獲取用戶的需求,開發出來的原型本身可以作為 下一步開發的根底,增量式
11、地完成開發)為了討論軟件運行的流程,可以采用 UM的Use Case圖。2、需求分析在了解用戶的需求之后,將需求用一種模型來表示,就是需求分析,目前比 擬流行的 分析方法是面向對象的方法,通過分析用戶需求,用類、類之間的各 種關系來表示整個系統。這局部涉與到具體的方法,在此不詳細討論,但是原如此上是提取類-> 類之 間關系,可能需要不斷修改而形成一份分析文檔。3、設計過程設計階段的工作包括:對分析模型必要的修改。可能需要對某些類結構進展一些修改, 這些修改的 原因可能是編程環境的要求,或者為了重用以前的某些工作。 定義界面局部、數 據訪問(數據庫)局部。由于目前很多編程語言都可以可視化地
12、設計界面, 所以界面局部工作往往留 到了編碼階段來完成。于是設計階段的工作量并不大。4、編碼進入編碼工作之后,可能會發現前面分析或設計階段的某些錯誤, 這時應返 回到前面的階段進展必要的修改。5、測試如前所述,即使是小項目,也應該嚴格地進展測試。2-4需要強調幾個問題一、是要分清問題域與系統責任。系統責任是指所要開發的軟件應該完成的功能, 而問題域是包含所有相關的 局部。例如你要開發一個程控機計費程序, 程控機已經是現成,輸出的數據格式 也已經是固定的,你的程序僅僅需要從程控機中讀取相應的信息,那么,程控機在你的系統里只是一個外部的東西,把它作為一個類也許就是不必要的,僅僅需 要一個類來完成讀
13、數據的操作。又如,你需要在一個已經存在的數據庫上開發一 些應用,數據庫的格式已經固定,并且已經有一個后臺程序在運行,你需要開發 一個新的前臺程序,這時,服務器程序對你來說就是一個外部的東西。但是,象 這種外部的內容必須在分析文檔中有一些說明,作為系統的外在約束。二、是需求獲取與需求分析的關系。用什么方法來完成需求的獲取,在很大程度上影響了需求分析的做法。 例如 當初采用Use Case來表示用戶需求,那么從各種序列圖中選出相互交互的各個 實體,就是一個個類。三、是分析與設計過程的銜接。分析過程的內容是用類的結構來表示目標系統, 并不設計具體實現,如采用 什么編程語言,在什么操作系統平臺上運行等
14、等。這些具體實現是在設計階段 來完成的。面向對象方法的優點是分析、設計、編碼過程表示法統一,能比擬好 的銜接。但是,是把分析和設 計階段分開,采用瀑布式開發,還是采用其他方 式,要看具體的情況。對于需求潛在變化不大的項目,可以采用瀑布模型,有一個很明顯的設計階 段,這樣做的好處是有一份比擬完整的分析文檔,這樣以后如果需要采用不同的 編程語言、或者采 用其他的平臺時,便可以以這份分析文檔作為開發的根底。對于需求變化頻繁的項目,可能采用少量分析;少量設計少量編碼測試的方 式更適宜,而且隨時可能要返回到前面某個一階段去進展修改。但是這意味著可 能沒有一份完整的分析文檔。現在很多CASE工具并不區分分
15、析和設計的階段。但是,這并不意味著開發 就可以對分析和設計不加區分,CASE工具如同一支筆,如何用好還得還人。四、人員的安排比擬小的項目,往往是幾個人來完成,這幾個人根本上從頭到尾參加開發。 在這幾個人中,有一位項目負責人,負責分析、設計和協調的工作。由于項目小, 項目負責人也要參加編程,那么這人必須把時間合理運用。第三局部小結我過去開發過的項目:小型藥店收費系統代碼數量:3000行開發周期:1個月 開發環境:VB武警執勤數據庫代碼數量:7500行開發周期:1個月 開發環境:VFP網絡視頻會議系統代碼數量:12000行開發周期:3個月 開發環境:VC# 根本上都存在這樣的問題:1 缺乏詳細的需
16、求分析。習慣了的個人開發模式是,詳細了解項目的要求 與功能之后,開一個根本的框架,即小樣。不斷與用戶溝通,細化到每個組件子 程序的詳細功能,并進展測試,逐步完善。因為缺乏全局的需求分析,經常反工, 浪費大量的時間和人力物力。2. 沒有完整的開發文檔。一個完整的軟件項目應包括以下的相關文檔:項目開發計劃測試分析報告概要設計說明書測試計劃操作手冊模塊開發卷宗用戶手冊 項目開發總結報告 詳細設計說明書 數據要求說明書 軟件需求說明書 可行性研究報告 開發進度月報 數據庫設計說明書 模塊開發卷宗 用戶手冊 項目開發計劃 項目開發總結報告 而在實際中,只有簡單的用戶操作手冊和開發日志。由于缺乏詳細的開發
17、文檔, 導致軟件的開發完全脫離計劃,對開發周期有相當大的影響;所有的資料全部包 含在軟件中,加大了和用戶溝通的難度;后期的軟件測試和維護無章可循。3沒有專門的美工和測試人員。開發出的軟件成品,外觀較差;自己設計 的代碼自己測試,這是軟件測試的大忌,給后期的系統全局測試留下較多的隱患。 是開發周期變長,本錢變大。幾乎全局測試要占用整個開發周期的一半以上! 經驗告訴我幾條原如此:1、協調幾個人的工作比自己完成一段編碼更重要。由于協調上出了漏洞,可能導致很大的問題,所以項目負責人必須隨時監控 各開發人員的工作,包括內容是否與要求發生偏差,進度是否滯后等等。只有在完成這些工作之后,項目負責人剩下的時間
18、才能用于編程。2、給每個開發人員明確的任務書。不管是用面向對象或者其他方法開發,分析、設計模型只是從功能的角度來 描述系 統。但是,具體開發時每個開發人員必須非常明確自己的任務,這些任 務應該采用明確的文檔來表示。3、讓大家都大致熟悉設計模型。讓每個開發人員都清楚自己所做的工作在整個系統中處于什么地位,有時侯可能會發現設計模型中的漏洞,防止了各人的代碼編寫完畢之后又要修改的后 果。2005年5月【注釋】Barry W.Boehm博士是軟件業中最有影響的專家之一,他開創并開展了COO II模型。他的經典著作Software Engineering Economics 軟件工程經濟學奠定了軟件本錢
19、估算領 域的根底。Boehm博十與美國南加州大學軟件工程中心的其他同事一起,引領著軟件本錢估 算技術的開展。軟件危機指的是在計算機軟件的開發和維護過程中所遇到的一系列嚴重問題。1968年北大西洋公約組織的計算機科學家在聯邦德國召開的國際學術會議上第一次提出了“軟件危 機"(software crisis)這個名詞。概括來說,軟件危機包含兩方面問題:一、如何開發軟件,以滿足不斷增長,日趨復雜的需求;二、如何維護數量不斷膨脹的軟件產品。Unified Modeling Language,統一建模語言。1997 年,0M(組織Object ManagementGroup對象管理組織發布了統
20、一建模語言。UML的目標之一就是為開發團隊提供標準通用的設計語言來開發和構建計算機應用。UML提出了一套IT專業人員期待多年的統一的標準建模符號。通過使用UML這些人員能夠閱讀和交流系統架構和設計規劃-就像建筑工人多年來所使用的建筑設計圖一樣。UML是一種定義良好、易于表達、功能強大且普遍適用的建模語言。 它溶入了軟件工程領域的新思想、新方法和新技術。它的作用域不限于支持面向對象的分析與設計,還支持從需求分析開始的軟件開發的全過程。用例視圖(use case view)。用例圖描述了系 統提供的一個功能單 元。用例圖的主要目的 是幫助開發團隊以一種 可視化的方式理解系統 的功能需求,包括基于 根本流程的”角色”actors,也就是與系 統交互的其他實體關 系,以與系統內用例之間的關系。用例圖一般表示出用例的組織關系-要么是整個系統的全部用例
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
- 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 六年級學困生技能提升輔導計劃
- 2024-2025小學語文教研組團隊建設計劃
- 小學體育教師備課計劃
- 校企合作中德育人員職責劃分
- 公共服務企業文化學習心得體會
- 雙語學校推廣普通話工作總結范文
- 校園學生健康管理措施
- 文化館裝飾裝修成品保護措施總結
- 工業廠房腳手架搭設安全措施
- 高三歷史閱讀理解提升計劃
- 少兒健康運動課件
- 應急救援無人機系統應用解析
- 2025北師大版新教材七年級上冊英語單詞表(精校打印)
- 2025至2030年中國電弧故障斷路器(AFCI)行業市場競爭態勢及產業前景研判報告
- 2025年安徽省中考英語試卷(含答案)
- 思想道德與法治2023年版電子版教材-1
- 物聯網安全風險評估-第2篇-洞察闡釋
- 上汽英飛凌無錫分公司第二代框架式功率模塊產品導入年產150萬片模塊項目環評資料環境影響
- 2025注冊核安全工程師考前沖刺試卷帶答案
- 國家數據局《2024年“數據要素×”項目案例集》
- (2025)行政能力測試題庫與答案
評論
0/150
提交評論