軟體開發如何項目管理

A. 開發軟體的項目管理方法

開發軟體的項目管理方法，也離不開九大范疇：范圍管理、時間管理、費用管理、質量管理、人力資源管理、風險管理、溝通管理、采購管理、綜合管理。只是要強調一下范圍管理中的需求管理，要認真做需求調研和分析，要有一流的工程師建模。要特別注意團隊之間的分工與協作。

B. 軟體項目管理的內容有那些

《軟體項目管理的內容》
軟體項目管理的內容主要包括如下幾個方面：人員的組織與管理，軟體度量，軟體項目計劃，風險管理，軟體質量保證，軟體過程能力評估，軟體配置管理等。
這幾個方面都是貫穿、交織於整個軟體開發過程中的，其中人員的組織與管理把注意力集中在項目組人員的構成、優化；軟體度量把關注用量化的方法評測軟體開發中的費用、生產率、進度和產品質量等要素是否符合期望值，包括過程度量和產品度量兩個方面；軟體項目計劃主要包括工作量、成本、開發時間的估計，並根據估計值制定和調整項目組的工作；風險管理預測未來可能出現的各種危害到軟體產品質量的潛在因素並由此採取措施進行預防；質量保證是保證產品和服務充分滿足消費者要求的質量而進行的有計劃，有組織的活動；軟體過程能力評估是對軟體開發能力的高低進行衡量；軟體配置管理針對開發過程中人員、工具的配置、使用提出管理策略。因為大家對人力資源管理和軟體過程能力比較有興趣，下面就詳細的對這兩方面展開討論。
從軟體工程的角度講，軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟體項目管理時，重點將軟體配置管理、項目跟蹤和控制管理、軟體風險管理及項目策劃活動管理四方面內容導入軟體開發的整個階段。在20世紀80年代初，著名軟體工程專家B.W.Boehm總結出了軟體開發時需遵循的七條基本原則，同樣，在進行軟體項目管理時，也應該遵循這七條原則。它們是：
1、用分階段的生命周期計劃嚴格管理；
2、堅持進行階段評審；
3、實行嚴格的產品控制；
4、採用現代程序設計技術；
5、 結果應能夠清楚地審查；
6、開發小組地人員應該少而精；
7、承認不斷改進軟體工程實踐的必要性。

C. 請討論如何進行軟體項目管理

軟體項目管理的對象是軟體工程項目。它所涉及的范圍覆蓋了整個軟體工程過程。 為使軟體項目開發獲得成功，關鍵問題是必須對軟體項目的工作范圍、可能風險、需要資源（人、硬體/軟體）、要實現的任務、經歷的里程碑、花費工作量（成本）、進度安排等做到心中有數。 這種管理在技術工作開始之前就應開始，在軟體從概念到實現的過程中繼續進行，當軟體工程過程最後結束時才終止。
軟體項目管理是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對人員（People）、產品（Proct）、過程（Process）和項目(Project)進行分析和管理的活動。
軟體項目管理的根本目的是為了讓軟體項目尤其是大型項目的整個軟體生命周期（從分析、設計、編碼到測試、維護全過程）都能在管理者的控制之下，以預定成本按期，按質的完成軟體交付用戶使用。而研究軟體項目管理為了從已有的成功或失敗的案例中總結出能夠指導今後開發的通用原則，方法，同時避免前人的失誤。

D. 為什麼要在軟體開發過程中進行項目管理

軟體項目管理的內容包括人員的組織與管理 、軟體配置管理 、軟體開發。軟體項目管理是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。軟體是純知識產品，開發進度和質量很難估計和度量，生產效率也難以預測和保證；項目周期長，復雜度高，變數多；軟體需要滿足一群人的期望。軟體開發主要分為六個階段：需求分析階段、概要設計階段、詳細設計階段、編碼階段、測試階段、安裝及維護階段。不論是作坊式開發，還是團隊協作開發，這六個階段都是不可缺少的。根據公司實際情況，公司在進行軟體項目管理時，重點將軟體配置管理、項目跟蹤和控制管理、軟體風險管理及項目策劃活動管理四方面內容導入軟體開發的整個階段。軟體開發過程的成功有賴於完善而正確的項目監控，如果沒有度量作為監控的信息，事實上監控將沒辦法實現，更不可能進行正確的項目調整。我們將通過一個完整的面臨崩潰的項目案例，通過項目監控和啟動拯救過程的實踐，討論在監控過程中如何充分利用度量數據，以有序的、理智的、經過很多成功拯救經驗積累出來的方法，使項目重新走向成功的經驗，來理解項目監控的本質。大型軟體項目是依靠一個組織來完成的，如果這個組織在管理上是無序的，開發過程是非正式和混亂的，計劃期限和成本目標通常超限，項目的成功取決於個人英雄式的行為，在人員發生變動時項目往往陷入災難，那麼很難說這個項目會獲得成功。從這個意義上說，軟體項目管理和過程管理是項目成功的關鍵因素。我們今天所面對的軟體開發問題，最重要的莫過於如何用一種有效的方式來組織項目，確保軟體開發的高效率。這就需要研究項目管理的本質，更加清醒地審視軟體開發中的問題，根據軟體的特點與文化背景創造出更好的管理方法。

E. 軟體需求該如何管理

啟動軟體項目的原因是軟體需求的存在,軟體開發模型有瀑布模型、快速模型和增量模型等,但無論採用哪一種模型,軟體需求分析是軟體開發過程的基礎。在軟體開發統計數據中,軟體項目中40%~60%的問題都是在需求分析階段埋下的隱患。而在以往失敗的軟體項目中,80%的失敗項目是由於需求分析的結果不明確造成的。因此，一個軟體項目成功的關鍵因素之一就是對需求分析的把握程度,而軟體項目的整體風險往往表現出需求不明確、業務流程不合理,所以,需求管理是項目管理的重要一環。
軟體需求是:①用戶為解決某一問題或達到某一目標所需條件或權能;②系統或系統構件為了滿足合同、規約、標准或其他正式實行的文檔所需具有的條件或權能;③一種反映上述①或②所述條件或權能的文檔說明。它包括功能性需求及非功能性需求,非功能性需求對設計和實現提出了限制,例如性能要求、質量標准,或者設計限制。
軟體需求就是指用戶希望軟體能做什麼事情,實現什麼樣的功能,達到什麼樣的性能。因此,軟體項目管理人員要准確地理解用戶所提出的要求,進行細致的需求調查分析,將用戶的非形式化的需求陳述轉化為完整的需求定義,並依據此定義轉化為需求規格說明書。

F. 軟體開發過程當中項目管理應注意的事項有哪些

現在項目管理很快被提到了一定的高度，並且在軟體的開發過程中起著至關重要的作用。管理項目要注意的事項一般有以下幾點: 首先是要確定開發的模型，開發模型的好壞直接關繫到一個項目的成功與否，只要有了好的開發模型就可以控制住項目的進度從而降低風險 早期的開發模型是一個文檔的驅動流程，一般會將軟體的開發分為幾個階段，只有在完成了一個階段後才能進入下一個階段。只有當所有的模塊都開發完成後才可以進行系統的集成，但是，這是一個艱巨的任務，還有一定的風險 傳統的軟體開發流程中會遇到很多的問題，針對其問題建議各位使用迭代化的開發方法。它就是為了完成一定階段的目標進行的開發活動。一般包含了需求調研、軟體實現、版本集成以及軟體發布等開發活動 此外，還要制定開發計劃，當確定好項目開發模型後，一整套項目開發計劃就是開發過程當中用戶和公司管理層了解項目進展的一個根據。一般而言，項目的管理層人員以及需求分析人員都會跟據用戶之前的需求，來定義整個項目實施過程中的項目迭代過程，還有每個迭代過程中的開發目標以及范圍。

G. 什麼是軟體項目管理

隨著信息技術的飛速發展，軟體產品的規模也越來越龐大，個人單打獨斗的作坊式開發方式已經越來越不適應發展的需要。各軟體企業都在積極將軟體項目管理引入開發活動中，對開發實行有效的管理。
從概念上講，軟體項目管理是為了使軟體項目能夠按照預定的成本、進度、質量順利完成，而對成本、人員、進度、質量、風險等進行分析和管理的活動。但是，國內權威的項目管理研究專家譚小芳老師認為，軟體項目管理的意義不僅僅如此，進行軟體項目管理有利於將開發人員的個人開發能力轉化成企業的開發能力，企業的軟體開發能力越高，表明這個企業的軟體生產越趨向於成熟，企業越能夠穩定發展（即減小開發風險）。

H. 軟體開發管理如何風險管理

風險管理的達成必須包括三個要素：

首先，在項目開發計劃中必須制定風險管理計劃；

第二，在項目預算中必須包含解決風險所需的經費；

第三，評估風險時，風險的影響也必須納入項目計劃中。

下面就軟體開發過程中經常發生的風險，談談我們採取的預防措施。

1、需求不明確

需求不明確是軟體開發過程中經常可能遇到的問題，這類問題往往表現在需求范圍未界定、需求未細化、需求描述不清楚、需求遺漏、需求互相矛盾等多個方面。在軟體開發過程的生命周期各階段中，需求不明確所造成的浪費是最大的，必須盡早盡可能解決。確定用戶需求是件非常困難的事情，我們常常從以下幾個方面著手處理需求不明確問題：

（1） 讓用戶參與開發

提供一個協作開發環境，讓用戶參與開發過程。如果條件不允許，至少應該在每次迭代的需求分析和系統測試階段，讓客戶能夠參與開發。

在選擇參與開發過程的用戶時，一方面，要盡可能爭取精通業務或計算機技術的用戶參與。另一方面，如果開發的產品要在不同規模、不同類型的企業應用，應該選擇具有代表性的用戶參與。

僅僅讓用戶參與是不夠的，應該採取一定的激勵措施，提高用戶參與的積極性。

（2） 開發用戶界面原型

用戶通常不善於精確描述自己的業務需求，系統分析員需要藉助白板、白紙等溝通方式，幫助用戶清楚表述需求。然後，開發一個用戶界面原型，以便用戶確認需求。用戶界面原型的作用僅僅是收集用戶需求，不應該再作它用，也不要給用戶造成系統快要實現的錯覺。

（3） 需求討論會議

對於用戶分布廣、用戶量大的項目，要全面收集用戶需求，往往很困難，通常採取需求研計會議方式進行需求確認。通過在會議前幾周調查各地、各部門用戶需求意見，然後集中各地或各部門的用戶代表，舉辦一次需求研討會，通過會議方式收集需求。本方法適合於具有一定信息系統使用經驗的用戶。

（4） 強化需求分析與評審

首先，需求分析是項目成功的基礎，需要引起足夠的重視，並分配充足的時間和人力，要讓有經驗的系統分析員負責，切忌讓項目新手或程序員負責。其次，要進行需求評審，盡可能讓用戶參與需求評審，不要讓需求評審流於行式。第三，也是最重要的一點，通過評審的需求規格說明書，要讓用戶方簽字，並作為項目合同的附件，對雙方都具有約束力。在公司內部要將通過評審的需求規格說明書，納入配置管理。

2、項目缺少可見性

當一個項目經理或一名開發者說已經完成了80%的任務，您必須保持審慎的態度。因為剩下的20%可能還需要80%的時間，甚至永遠都不能完成[1]。軟體開發項目，往往在項目進度和軟體質量方面缺少可見性，項目越缺少可見性，項目就越難以控制，項目就越有可能失敗。我們可以通過迭代開發、技術評審、持續集成來增強項目的可見性。

（1） 迭代開發

採用迭代的開發模型，將產品的交付過程分為多個階段，按照功能遞增式交付。以下是一些典型的迭代：

一次簡短的先期迭代，以建立規模和前景並確定商業理由；

一次精化迭代，其間將為穩定的構架劃定基線；

一次構建迭代，其間將實現用例並充實構架；

幾次產品化迭代，將產品轉移到用戶群。

每次迭代，都要充分接收用戶的評審意見，以便為自我糾正。漸近式的功能交付，有利於降低開發人員的壓力，增加用戶的滿意度，有利於增強項目的可見性，是最好的進展報告。

（2） 技術評審

技術評審是確保軟體質量的重要環節，技術評審包括代碼走查、會議評審和同行專家評審。代碼走審可以是開發人員之間的交叉審查，或者是高級開發人員對普通開發人員的審查；會議評審一般應至少每兩周進行一次，每次評審時間不宜太長；同行專家評審包括技術和業務兩個方面的專家，經常性地讓精通業務的用戶專家參與項目評審，是項目成功的重要保證。

另外，充分利用質量審查的工具軟體，也有利於提高代碼質量。例如：在Eclipse開發環境中，可以集成Findbug、Checkstyle、PMD插件檢查代碼編寫質量。

（3） 持續集成

持續集成能夠把最終的一次大規模的集成調試過程分散到項目開發時間表的每一周、每一天、甚至每個小時。讓項目中的各個人員都能夠隨時掌握當前的整體進度，並迅速發現集成過程中出現的問題並進行解決[1]。

開發小組應制定持續集成的制度，一般情況下每日構建一次，可以利用Ant等構建工具進行Java應用程序的構建。小組成員應在每個功能開發完成後，及時向版本控制系統（如CVS）提交代碼，而且不應該向版本控制系統提交有問題（編譯通不過）的代碼。

每日構建、持續集成，讓項目進度跟蹤工作更加容易。當項目小組每天重新編譯系統時，已完成與未完成的功能清楚可見，小組成員能夠簡單地從軟體的表現知道距離整體完成還有多遠。

3、新技術引入

技術創新是一種具有探索性、創造性的技術經濟活動。在開發過程中引入新技術，不可避免地要遇到各種風險。通過T形軟體開發、充分論證、多階段評審、同行經驗等措施可降低新技術風險。

（1） T形軟體開發

在項目開發早期，開發小組應該建立系統的架構，解決關鍵技術難題、開發系統的基礎構件，並對系統所需要應用的技術做深度探索。例如：基於JavaEE5構建全國聯網售票系統，涉及到分布式事務處理、海量數據存儲、異構平台互連等關鍵問題，應該優先處理這些問題；對開發所涉及到的EJB3、JSF、 JBoss Seam、Eclipse RCP等技術，要做深度探索。

越是技術復雜度高的項目，就越應該早地處理技術難題。如果在項目開發的中期或後期才發現架構有問題或是關鍵技術難題不能解決，則為時已晚。

（2） 充分論證

新技術開發是探索性很強的工作，潛在著許多失敗的風險。在可行性分析階段，要廣泛搜集相關信息，設計多種可行方案，進行充分論證。在制定決策時，情報的數量和質量致關重要。掌握的信息越多、越准確，才能作出正確的的決策，項目失敗的風險也就相對減少；反之，承擔的風險就會增大。

（3） 同行經驗

針對新技術，由於沒有經驗可借鑒，因此在探索過程中要充分利用互聯網，通過搜索同行經驗，往往事半功倍。要充分利用世界日益平坦化的優勢，對於不能盡快解決的問題，可以先放一放，可能過不了幾天，網上就有相類似問題的解決方案了。

4、技術兼容性風險

硬體產品之間、系統軟體（操作系統、中間件、資料庫管理系統）與主機設備之間、系統軟體之間、應用軟體與系統軟體之間以及應用軟體之間，都可能存在兼容性問題。往往系統集成的項目越復雜，兼容性問題就越有可能存在。

（1） 設計先行

在做系統的總體設計方案時，務必把好相關產品的選型關，確保網路、主機、系統軟體與應用軟體之間不要存在較大的技術兼容性問題。在網路平台建設方案中，明確相關設備的技術參數和配置要求。

（2） 售前產品測試

在做項目招投標工作時，要求投標方在售前提供產品兼容性測試，以避免在項目實施過程中才暴露技術兼容性問題。涉及應用軟體開發的集成項目，要在開發工作的早期，做技術兼容性測試，以避免在項目開發後期才暴露技術兼容性問題。

例如，我們在開發深圳市汽車客運站售票及站務聯網調度系統時，為了確保技術兼容，在做硬體招標時要求小型機設備廠商提供售前技術兼容性測試工作，並將測試結果做為評標指標。在深圳市軟體測試中心對IBM、SUN、HP三家公司提供的小型機進行測試時，暴露了許多應用軟體、應用伺服器、資料庫和操作系統之間的技術兼容性問題，如果這些問題在系統實施時才暴露或處理，勢必會拖延項目進度。

5、性能問題

由於先期設計不足，性能問題往往在系統切換或新系統使用一段時間後暴露。出現性能問題往往要進行大量的優化工作，甚至局部的或全面的重新設計。無論是用戶還是開發者，誰都不希望出現性能問題。

（1） 性能規劃

在系統設計時，應做好前期做性能規劃，對可能出現性能問題的環節做到充足的估計。在做資料庫設計時，應爭取DBA參與。

另外，在技術方法方面，盡可能採取一些性能優化模式，如DTO、AJAX、延遲載入等，盡可能在開發過程中解決了性能問題。不至於到了項目後期才解決性能問題，既費錢又費時。

（2） 性能測試

在開發過程中，要重視性能測試和壓力測試，盡可能模擬現實使用環境，搭建測試平台。另外，由於開發環境的計算機往往比生產環境的計算機配置高，在做測試時應盡量找一些配置低的機器、較小的網路帶寬進行測試。

（3） 充足的調試時間

在項目開發計劃中，為後期性能優化留有餘地。在對系統進行性能優化後，要進行性能測試和壓力測試，可能還要做幾次回歸測試。因此，應該留有充足的時間和人力。

6、倉促上線

在項目實施過程中，系統切換上線環節最容易出紕漏。項目好不容易開發完成了，卻在最後最後時刻功潰一匱。如果項目小，影響面窄倒不怎麼重要；如果是影響面大的項目，則千萬不可出現問題。在系統切換前，應充分考慮各種可能出現的問題，做好風險對策。

（1） 應急預案

面對各種不可預知的風險，要做好應急預案。正常運行的車站售票系統在春運、旅遊黃金周，都會做好應急預案。新系統切換時，更應該做好應急預案。應急預案中應做好最壞的打算，售票系統不能正常工作時，准備手工票就是最壞的打算。

（2） 分步切換

為了減少風險的影響，可以做系統分步切換的方案。例如：售票系統在切換時，往往用新系統售預售票，或者是用新系統售長途車站，用舊系統暫時售短程票。待新系統運行穩定後，再全面切換到新系統。針對多個用戶單位的系統切換，也可分單位進行。

（3） 交叉培訓

新舊系統切換過程中，用戶都存在適應過程。除了在切換前做好操作培訓外，還要在新舊系統切換過程中做好交叉培訓。讓用戶提前一些時間上班，讓早班的用戶在交班時培訓中班的用戶，中班的用戶培訓晚班的用戶。做好交叉培訓能夠讓系統平衡過渡。

7、可用性問題

軟體的可用性包括軟體的使用是不是高效、是否容易學習、是否容易記憶、是否令人愉快、是否不易出錯等諸多因素。往往由於軟體的可用性差，導致用戶不滿意，甚至被市場淘汰。在項目開發中應注意可用性問題，避免軟體出現可用性方面的風險。

（1） 了解用戶

到用戶工作現場，了解目標用戶使用軟體的真實目的，從用戶的角度、從用戶的立場出發，了解如何通過軟體系統替代用戶的業務處理流程中，最繁瑣、最容易出問題、或者是大量重復勞動的環節，讓軟體提高用戶的工作效能和效率。例如：售票系統中，使用頻度最高的界面是售票界面，售票員最關心的是錢不要出錯（多了沒收、少了要賠），因此，應收款和找余字體的顯示應該突出、醒目；同樣，票價和到達站也應該較為突出顯示。通過快捷鍵、一鍵復位、數字小鍵盤等設計，盡量減少售票員敲擊鍵盤的次數。否則，在日發旅客流量達七、八萬人次的大型客運站，如果用戶界面設計得不好，售票員一天工作下來，手指都會敲麻木。

（2） 參與型設計

與用戶協作，讓用戶參與用戶界面的設計、評審與測試，確保用戶能夠全面地、及早地發現可用性等方面的問題，並及時糾正。

讓客戶參與設計，而不要讓客戶設計，項目經理或高級設計人員應該主導設計。

（3） 競爭性分析

通過對市場上同類競爭性產品進行分析，或者對這些產品進行實驗性測試，了解這些產品的用戶界面問題，從而對新系統的開發提供啟發。競爭性分析並不意味著可以剽竊別人的設計，而是通過分析競爭產品的優勢和弱點，能夠比以前的設計做得更好[5]。

（4） 一致性

如果用戶知道同樣的命令或同樣的操作總會產生同樣的效果，那麼他們在使用系統時就會更加自信，同時也鼓勵他們進行探索性學習，因為他們已經具備了使用系統新部分的基礎知識[Lewis er al。1989]。

開發團隊應遵循公司或小組制定的用戶界面標准，就可以在很多方面保持一致性，切忌不要一個系統存在多種不同的界面風格。

鄭州觀致電子商務,擁有有效資源, 多起成功案例, 專業製作水平, 提供微期貨平台搭建、分銷系統開發、捕魚游戲開發、第三方支付軟體開發、商城網站建設、電商網站建設、網站定製開發、手機app軟體開發、微信小程序開發、電商系統開發、辦公系統軟體開發一系列服務。精英團隊為您以後保駕護航!

8、結論

在信息系統集成項目中，風險是多種多樣的，是無處不在的。在項目管理活動中，要積極面對風險，要培養。越早識別風險、越早管理風險，就越有可能規避風險，或者在風險發生時能夠降低風險帶來的影響。特別是在項目參與方多、涉及面廣、影響面大、技術含量高的復雜項目，應加強風險管理。如果不主動駕馭風險，就會面臨風險。

I. 軟體開發的項目,如何進行范圍管理

在項目一開始時，紅匣子科技首先對項目進行可行性研究，接著進行成本分析，並把結果做成一份報告，交於領導批准。在項目的整個生命周期中，我們把項目管理工作分為五個過程組：啟動、計劃、執行、監控與收尾。

項目啟動階段

收尾階段

項目收尾階段是完結項目管理所有活動以正式結束項目或階段的過程。在項目結束後，項目經理需要審查以前各階段的收尾信息，確保所有項目工作已完成。整個項目結束，要對整體的項目做個總結，並且進行產品的測試階段。