文檔管理論文

開篇：寫作不僅是一種記錄，更是一種創造，它讓我們能夠捕捉那些稍縱即逝的靈感，將它們永久地定格在紙上。下面是小編精心整理的12篇文檔管理論文，希望這些內容能成為您創作過程中的良師益友，陪伴您不斷探索和進步。

第1篇

相關熱搜：項目管理  軟件項目管理  項目管理工程

隨著計算機硬件水平的不斷提高，計算機軟件的規模和復雜度也隨之增加。軟件項目中一些問題也應運而生：項目無法按期完成、項目合作方的工作難以協調、用戶需求經常變動、工作質量難以保證。為了避免愈來愈多的“項目黑洞”給企業帶來的損失，各個軟件企業都將軟件項目管理引入到開發活動中來，對開發實行有效的管理。

一、軟件項目引入項目管理的必要性軟件項目即軟件開發項目，是一個用計算機程序和相關技術文檔把思想表達出來的過程。軟件項目所涉及到的內容大多是無形的東西，既看不到質，也看不到量，從而使軟件項目的管理難度加大。

隨著信息技術的飛速發展，軟件產品的規模也越來越大，完全由個人完成一個軟件項目幾乎是不可能的，軟件項目的開發都是以項目組為單位完成的，這必然涉及到對軟件項目的管理。一個軟件項目的成敗，不在于其項目組的技術人員的技術水平，而在于是否采用合適的管理方式。好的管理方式不一定能使項目完全成功，但是一個不合適的管理模式肯定會導致軟件項目的失敗。

項目管理是指在一定資源如時間、資金、人力和設備等約束條件下，對一個有既定目標(質量、投資、進度)要求的任務進行計劃和控制的過程。項目管理以系統的觀點來對一個項目進行全程的控制，同樣也可以用此來完成對軟件項目的管理，而且由于軟件項目的特殊性，項目管理在應用于軟件項目的管理時，也會有其獨特的一面。在項目管理應用于軟件項目的管理方面，已經有了不少成功的案例。

二、影響軟件項目管理的關鍵要素

(一)可靠的軟件需求

軟件需求是軟件項目的根本所在，需求不明確，工作就沒有方向，因此影響軟件項目的第一個因素就是項目要有一個可靠的需求。軟件需求應當是項目有關的人員一致同意的、清楚的、完整的、詳細的、可實現的和可測試的。

需求的確定，開發者應該認真聽取用戶的意見，并進行記錄，反復和用戶溝通，不能想當然地把自己的想象當作用戶的需求。在確定用戶需求的時候，應該盡可能從專業的角度發掘用戶的潛在需求，以達到最大限度地滿足用戶的目標，只有這樣才能可能開發有價值的軟件項目。一定要強調的是，在項目開始以后，應該盡最大可能不更改需求，要與用戶進行很好地溝通，以確保開發工作能按照需求進行，也就是說，只有有了可靠的需求，項目開發才有基本保證。

(二)可行的項目計劃

凡事預則立，不預則廢。這里的預就是指計劃。明確了項目目標，還必須有一個切實可行的計劃。軟件項目計劃的目的是為完成軟件工程和管理軟件項目。制定合理的計劃，它包括以下步驟:估計軟件

產品規模及所需的資源，制定時間表，鑒別和評估軟件風險和協商約定，而且要標志出幾個階段性的里程碑，這是極為關鍵的一點。對于軟件企業來說，一個可行的計劃的重要性是不言而喻的。但是在一些單位，很多人都聽過這樣的一句話一“計劃趕不上變化”。這種變化對某些行業來說也許并不會產生太大的影響，但是對于軟件企業來說，卻會對軟件產品的保證帶來嚴重的負面影響。造成這種現象的原因很多，主要是因為對計劃的重視程度不夠，計劃過于籠統、粗糙，導致可執行性差，再加上一些人為因素的影響，必然會產生一些不良的影響。因此，要想成功進行項目管理，就要對計劃高度重視，周密制定，嚴格執行。只有嚴格進行計劃，才能使項目管理得以成功實施。

(三）規范的操作流程

軟件開發流程非常規范和系統化，其流程的可執行性很高，并且能在實踐過程中不斷改進。流程是保證項目成功的一個關鍵因素。由優秀的項目成員按照規范的操作流程進行項目開發，才能最大限度地保證項目的成功。一個規范的流程可以保證不是很出色的人開發出來的，產品不至于太差，但不能保證做出精品，而一個不規范的流程很難做出好的產品。

通過流程可以實現一種規范化、流水線、工業化的軟件，從而最終實現成功的項目管理。對于軟件項目的每一個階段均要做出工作計劃并交有關部門監督執行，在階段結束之后，要對該階段的工作活動進行評價，并對后續階段的時間、人員、資金方面的需求做出估計。每個階段的工作成果需經項目的技術管理部門審查合格后，方能開始下一階段的工作。

(四）有效的人員溝通

軟件項目的實施對人的依賴性比其他行業更為突出，它是一項知識性極強的工作，因此對人的管理相當復雜，如何加強人員之間的有效溝通，是軟件項目成功的一個非常關鍵的因素。這里的溝通包括兩個方面：一個是軟件項目組開發人員與用戶的溝通;另一個是軟件項目組內人員的溝通。只有對用戶的需求非常明確，軟件項目的實施才有一個堅實的基礎。對用戶的需求不明確，開發出的軟件根本沒法用，所以這樣的項目在一開始就是失敗的。組內人員的溝通有助于在明確了用戶需求后，使得項目能按計劃進展，最后才有可能完成該軟件項目。

沒有最好的溝通方式，只有最有效的溝通。因此溝通因人因事而采用不同的溝通方式，才可以達到良好的效果。有時項目組需要和用戶溝通，面談是一種較為花時間的方式，而用戶方常常以忙來說明自己沒有時間，這時候可以采用電話溝通的方式，這樣馬上就可以得到答復。有時可以將項目進展情況用郵件的方式發給對方，使得軟件開發的工作也成為用戶的一種工作，只有這樣才能正確把握用戶的真正需求，才能使得開發出的軟件真正是滿足用戶需求的軟件。而在內部的溝通形式就可以多樣，如定期的項目溝通會議、項目進展文檔等。

總之，只有加強溝通，才能使得軟件項目順利實施，溝通是成功軟件項目管理的很重要的因素。

(五)健全的項目文檔

軟件項目的文檔在整個生命周期中的地位和作用尤為重要，無論怎樣強調都不過分。文檔作為軟件產品的主要形式，集中體現了軟件人員的勞動成果，沒有文檔就稱不上軟件。但是實際情況是許多軟件開發人員從一開始就不注重文檔的寫作，尤其是當軟件項目的工期又很緊張時，在沒有任何文檔或只有少量文檔的情況下就開始了具體的開發工作。有的寫了文檔，但是在開發過程中需求發生了變更，也沒有及時在文檔中體現出來，使得過一段時間后開發者對所開發的內容也記得不清了，當項目出現問題時，沒有有效的文檔可查，致使軟件項目延期或失敗。

軟件開發過程中各階段的文檔不健全，往往在項目接近尾聲時為了驗收才補寫文檔。最常見的是有系統分析與概要設計文檔，但是沒有詳細設計文檔，在程序開發過程中，開發人員往往最大限度地發揮著自己高超的編程技巧，以至于在后期維護時，因為沒有詳細的設計文檔，給項目的后期維護帶來困難。

編寫文檔的工作量是很大的。有時會占整個項目的40%,所以文檔的編寫會花費大量的時間和精力，但是有了好的文檔，會對后期的開發工作帶來很多的便利。健全的文檔管理是軟件項目成功實施的一個重要因素。

三、軟件項目管理的方法

軟件項目管理有階段化管理，量化管理和優化管理三個層面。

(―)階段化管理

階段化管理指的是從立項之初直到系統運行維護的全過程，將項目分成小的階段。比如，通常分為問題定義、可行性研究、需求分析、總體設計、詳細設計、編碼、狽彳試和維護等幾個階段。每個階段都有明確的目標和成果驗收，以及必要的監督回饋，這樣就能夠很好地減少項目負責人和客戶的分歧，增加項目風險的可控性。在項目負責人提交給客戶的需求分析和初始報告里，就已經把每個階段要完成的工作，可出的成果，甚至具體到有多少個界面，都能清晰的描述出來。這樣，在每個階段完成后，客戶和項目負責人都能夠比較清楚地了解項目的進展、完成情況，以及客戶對項目完成部分的滿意程度。同時，也方便進行項目組成員的績效評估。

(二)量化管理

把項目的方方面面盡可能地進行數量化，做到責任清楚。給客戶做軟件，時常碰到這種問題：某階段成果A(比如說，包括A1、A2、A3等不同部分）出來了，客戶看了以后，可能認為A1完全符合要求，A2根本就不對，A3雖然有毛病但改改還可用，等等。那么，這其中的問題出在哪里？責任該由誰負?責任又有多大呢?為此，必須把各種目標、投入、成果等分類量化。比如，用明確的模塊或子系統表達客戶需求，精確計算A1、A2、A3每部分花費人工、物力、財力等等。把各種量化指標存入數據庫，就能夠輕而易舉地解決上述的問題了。而且，每個階段都有清晰的量化管理，也非常有利于整個項目進程的推進。

(三）優化管理

優化管理就是分析項目每部分所蘊涵的知識、經驗和教訓，更好地發揚項目進程中的經驗，吸取教訓，在全公司傳播有益的知識。再如前面例子，通過分析發現A1部分的領頭人能力強，就可以讓他以后多帶幾個人，使他的知識和經驗更好地發揮成效。A2、A3部分為什么不成功？是客戶的需求沒提清楚，是理解的錯誤，還是有設計的問題？通過這些分析后，有利于進一步優化項目管理。

四、軟件項目管理過程中的幾個誤區

(一)對需求的修改是必然的，具體細節可在以后的開發過程中填充

在軟件項目的需求分析階段，軟件開發人員和項目負責人通常認為開發方與客戶方在各種問題的基本輪廓上達成一致即可，具體細節可以在以后填充。理由是無論開始時多么細致，以后對需求的修改幾乎是必然的。但在實際操作中，由于需求階段對問題的描述不夠細致，導致后來預算超支或者時間進度達不到要求的情況并不少見。正確的做法應該是:在項目需求分析階段，雙方必須全面地、盡可能細致地討論項目的應用背景、功能要求、性能要求、操作界面要求、與其他軟件的接口要求，以及對項目進行評估的各種評價標準。在需求分析結束以后，雙方還要建立可以直接聯系的渠道，以便盡早地對需求變動進行溝通。

(二)軟件項目的需求可以持續不斷地改變，并且可以很容易地得以實現

在需求分析階段，還有一個經常出現的問題，就是認為軟件項目的需求可以持續不斷地改變，而且這些改變可以很容易地實現。在具體實際中由于種種原因，客戶方很難在需求分析階段就能全面而準確地描述所有問題。隨著開發進度的推進，往往會有一些需求的改變。現代軟件工程理論也利用軟件的靈活性特點通過各種方式來適應這種情況。實踐表明:隨著開發進度的推進，實現軟件需求更改所需要的代價呈指數形式增長。假定在需求分析階段實現需求更改要花費1倍的代價，那么，在系統設計和編碼階段，則需要花費1.5~6倍的代價；在系統測試階段需要花費10~20倍的代價，在軟件版本以后，甚至要花費60~100倍的代價。由此可見，在項目開展過程中，軟件需求的改變應當盡早提出。這樣才能做到既節省開銷，又較容易實現。

(三)在系統詳細設計階段，必須寫出所有程序的偽碼

在詳細設計階段，起初為了便于代碼的維護修改，要求文檔工作應該做到寫出所有程序的偽碼。偽碼的最大作用是對程序的算法流程進行描述，便于人們深入了解程序的功能和實現過程。因此，偽碼在一定程度上的確有利于對程序代碼的維護和修改。但在實際工作中，這種做法卻很難實施。為了保證項目文檔和程序代碼的一一對應關系，維護程序代碼的同時也需要對項目文檔進行維護。偽碼和程序代碼非常接近，對偽碼進行維護，就相當于進行了加倍的程序代碼維護。為了趕進度，這種方法在實踐中往往會流于形式。所以，切合實際的方式應該是對一般的程序文檔做到程序流程圖即可，對涉及了較復雜算法的程序才需要偽碼。

(四)編碼階段是整個軟件項目中最重要的階段

在軟件開發階段，項目負責人往往認為軟件程序主要由代碼組成，因此編碼階段是整個軟件項目中最重要的階段，應該給予大量時間，集中主要資源。與編碼階段相比，需求分析、詳細設計以及測試時間較少，容易造成測試不完全及軟件上線后的先天不足，給今后的工作造成被動。如今，由于軟件的規模和復雜度都較以前有較大的增加，再加上半自動化軟件代碼開發平臺的出現，現代軟件項目管理的中心已經發生了轉移一不是著重編碼階段，而是著重系統總體/詳細設計階段。一般，系統總體/詳細設計階段應占整個軟件開發時間的一半。這樣才能充分考慮系統將會出現的各種問題及其解決辦法，為以后的編碼、測試工作爭取主動。

(五)軟件所有的內部測試工作應由測試人員完成

在軟件測試階段，由于在項目人員配置中設置了專門的測試人員，人們通常認為軟件所有的內部測試工作應該由測試人員完成。但這種做法往往會造成測試不全面，軟件交付后經常出現問題的情況。在實際工作中，由于使用“白盒法”對測試人員各方面素質有著較高的要求，進行程序測試時，測試人員總是優先使用“黑盒法'狽j試沒有通過才會考慮對程序代碼進行“白盒法”測試。顯然，這種對“白盒法，有意無意的“逃避”，對軟件的可靠性和穩定性構成了威脅。要解決這個問題，一方面需要提高對測試人員的要求;另一方面也需要讓程序員完成部分的“白盒法”測試。

(六)軟件項目管理只是相關技術部門的事，與公司其他部門無關

在競爭日益激烈的今天，軟件項目規模大、復雜度高，而且時間要求緊迫。要想提高公司的軟件項目管理水平，就需要提高公司的整體參與意識，需要公司各個部門協同作戰。例如，需要會計部門協助進行項目預算、財務管理和費用控制;需要研究部門(技術委員會)指派專家協助進行各種風險評估，提供技術指導;需要后勤部門提供各種保障。

(七)開發進度滯后時，可以聘請更多的程序員加入到開發團隊中，通過增加人力資源追趕開發進度

如今，在注重團隊開發的時代，開發方應該根據目前的軟件項目管理水平慎重考慮這個做法。如果新加入的程序員對目前軟件項目的應用行業有一定了角解并且可以很快地適應開發方的項目管理方式、軟件開發風格、團隊協作氛圍，那么“新人”的加入是有益的。否則，可能會“好心卻辦了壞事”。因為盡管新人的個人能力很高，但為了使其與大家一起協同工作，開發團隊不得不分出人手對新人進行與項目有關的技術、業務培訓。更重要，也是難度最大的是，還要引導新人融入到整個開發團隊中。這可能需要花費開發團隊大量的時間和精力，很有可能使項目進度更慢。