軟體工程/專案管理導論
軟體專案管理是計劃和領導軟體專案的藝術和科學[1]。它是專案管理的一個分支，其中軟體專案被計劃、監控和控制。
軟體專案管理的歷史與軟體的歷史密切相關。在面向物件程式設計的概念在 1960 年代開始流行之前，軟體是為專用機器開發的，用於專門用途，從而為軟體行業創造了可重複的解決方案。由於基於元件的軟體工程，專用系統可以適應其他用途。公司很快就瞭解到軟體程式設計相對於硬體電路的相對易用性，軟體行業在 1970 年代和 1980 年代迅速發展。為了管理新的開發工作，公司應用了成熟的專案管理方法，但在測試執行期間專案進度卻落後，尤其是在使用者規格說明和交付的軟體之間存在灰色區域時，會發生混淆。為了避免這些問題，軟體專案管理方法側重於將使用者需求與交付的產品匹配起來，這種方法現在被稱為瀑布模型。從那時起，對軟體專案管理失敗的分析表明，以下是最常見的原因：[2]
- 不切實際或未明確表達的專案目標
- 對所需資源的估計不準確
- 系統需求定義不明確
- 專案狀態報告不完善
- 風險管理不善
- 客戶、開發人員和使用者之間溝通不良
- 使用不成熟的技術
- 無法處理專案的複雜性
- 粗心大意的開發實踐
- 專案管理不善
- 利益相關者政治
- 商業壓力
上述列表中的前三項表明了以一種可以使適當的資源交付適當的專案目標的方式來表達客戶需求的難度。特定的軟體專案管理工具是有用的，通常是必要的，但軟體專案管理的真正藝術在於應用正確的方法，然後使用工具來支援該方法。沒有方法，工具就毫無價值。自 1960 年代以來，軟體製造商為自身使用開發了幾種專有的軟體專案管理方法，同時計算機諮詢公司也為其客戶開發了類似的方法。如今，軟體專案管理方法仍在不斷發展，但當前趨勢是遠離瀑布模型，轉向更迴圈的專案交付模型，該模型模仿軟體釋出生命週期。
軟體開發流程主要關注軟體開發的生產方面，而不是技術方面，例如軟體工具。這些流程主要用於支援軟體開發的管理，通常偏向於解決業務問題。許多軟體開發流程可以以與一般專案管理流程類似的方式執行。例如
- 風險管理是衡量或評估風險，然後制定策略來管理風險的過程。一般來說，採用的策略包括將風險轉移給另一方、避免風險、減少風險的負面影響，以及接受某個或所有特定風險的後果。軟體專案管理中的風險管理始於專案的商業案例，其中包括成本效益分析以及專案失敗的備用方案列表，稱為應急計劃。
- 風險管理的一個子集，即“機會管理”，正越來越受到關注。機會管理與風險管理含義相同，只是潛在的風險結果將產生積極影響，而不是負面影響。儘管在理論上以相同的方式處理，但使用“機會”而不是“風險”這個略帶負面意義的詞語，有助於讓團隊專注於專案中任何給定風險登記簿中可能產生的積極結果，例如衍生專案、意外之財和免費的額外資源。
- 需求管理是識別、徵求、記錄、分析、追蹤、優先排序和達成一致需求，然後控制變更並與相關利益相關者進行溝通的過程。新或更改的計算機系統[1]需求管理，包括需求分析，是軟體工程過程的重要組成部分；業務分析師或軟體開發人員透過此過程來識別客戶的需求或要求；在識別這些要求後，他們就可以設計解決方案。
- 變更管理是識別、記錄、分析、優先排序和達成一致變更範圍（專案管理），然後控制變更並與相關利益相關者進行溝通的過程。新或更改範圍的變更影響分析，包括變更級別的需求分析，是軟體工程過程的重要組成部分；業務分析師或軟體開發人員透過此過程來識別客戶的更改的需求或要求；在識別這些要求後，他們就可以重新設計或修改解決方案。從理論上講，每次變更都會影響軟體專案的進度和預算，因此根據定義，在批准之前必須包括風險效益分析。
- 軟體配置管理是識別和記錄範圍本身的過程，即正在進行的軟體產品，包括所有子產品和變更，並能夠與相關利益相關者進行溝通。一般來說，採用的流程包括版本控制、命名約定（程式設計）和軟體存檔協議。
- 釋出管理是識別、記錄、優先排序和達成一致軟體釋出，然後控制釋出時間表並與相關利益相關者進行溝通的過程。大多數軟體專案都可以訪問三個可以釋出軟體的軟體環境：開發、測試和生產。在非常大的專案中，如果分散式團隊需要在向用戶釋出之前整合他們的工作，那麼在釋出到使用者驗收測試 (UAT) 之前，通常會有更多用於測試的環境，稱為單元測試、系統測試或整合測試。
- 釋出管理的一個子集，即資料管理，正越來越受到關注，因為很明顯，使用者只能根據他們知道的資料進行測試，而“真實”資料只存在於名為“生產”的軟體環境中。因此，為了測試他們的工作，程式設計師也必須經常建立“虛擬資料”或“資料存根”。傳統上，以前曾使用生產系統的舊版本來實現此目的，但隨著公司越來越依賴外部貢獻者來進行軟體開發，公司資料可能不會發布給開發團隊。在複雜的環境中，可能會建立資料集，然後根據測試釋出時間表將這些資料集遷移到測試環境中，這與整體軟體釋出時間表非常類似。
專案規劃的目的是識別專案的範圍，估計所涉及的工作，並建立一個專案時間表。專案規劃從定義要開發的軟體的需求開始。然後，制定專案計劃來描述將導致完成的任務。
專案監控和控制的目的是讓團隊和管理層瞭解專案的進度。如果專案偏離計劃，則專案經理可以採取措施糾正問題。專案監控和控制包括狀態會議，以收集來自團隊的狀態。當需要進行更改時，可以使用變更控制來使產品保持最新。
在計算中，術語問題是指為了在系統中實現改進而要完成的工作單元。問題可以是錯誤、請求的功能、任務、缺少的文件等等。單詞“問題”通常被誤用，代替了“問題”。這種用法可能與之相關。 [需要引用]
例如，OpenOffice.org 曾經將其修改後的 BugZilla 版本稱為 IssueZilla。截至 2010 年 9 月，他們將其系統稱為問題跟蹤器。
問題會不時出現，及時解決這些問題對於實現系統的正確性並避免產品交付延遲至關重要。
問題通常按嚴重程度分類。不同的公司對嚴重程度的定義不同，但一些最常見的嚴重程度是
- 嚴重
- 高 - 錯誤或問題影響了系統的關鍵部分，必須修復才能恢復正常執行。
- 中等 - 錯誤或問題影響系統的一小部分，但對系統執行有一些影響。當系統的一個非核心需求受到影響時，會分配此嚴重性級別。
- 低 - 錯誤或問題影響系統的一小部分，並且對系統執行幾乎沒有影響。當系統的一個非核心需求（且重要性較低）受到影響時，會分配此嚴重性級別。
- 外觀 - 系統正常工作，但外觀與預期不符。例如：顏色錯誤、內容之間間距過多或過少、字型大小不正確、錯字等。這是最低優先順序的問題。
在許多軟體公司中，問題通常由質量保證分析師在驗證系統正確性時進行調查，然後分配給負責解決問題的開發人員。它們也可以在使用者驗收測試 (UAT) 階段由系統使用者分配。
問題通常使用問題或缺陷跟蹤系統進行溝通。在其他情況下，可以使用電子郵件或即時通訊工具。
作為專案管理的一個分支學科，有些人認為軟體開發管理類似於製造管理，可以由具有管理技能但沒有程式設計技能的人員執行。約翰·C·雷諾茲反駁了這種觀點，並認為軟體開發完全是設計工作，並將不會程式設計的經理比作不會寫作的報紙主編。[3]
- 來自 Steve McConnell 的軟體專案管理資源：http://www.construx.com/Page.aspx?nid=22
- 來自 Dan Galorath 的軟體專案管理資源：http://www.galorath.com/wp/category/project-management
- ↑ a b Stellman, Andrew; Greene, Jennifer (2005). 應用軟體專案管理. O'Reilly Media. ISBN 978-0-596-00948-9.
- ↑ IEEE 雜誌文章“為什麼軟體會失敗”
- ↑ John C. Reynolds，關於教授程式設計和程式語言的一些想法，SIGPLAN 通知，第 43 卷，第 11 期，2008 年 11 月，第 108 頁：“有些人認為，在沒有程式設計能力的情況下，可以管理軟體生產。這種信念似乎源於對軟體生產是一種製造形式的錯誤看法。但製造是重複構建相同的物體，而軟體生產是構建獨特的物體，即整個過程都是一種設計形式。因此，它更接近於報紙的製作——因此，不會程式設計的軟體經理就如同不會寫作的主編。”
- Jalote, Pankaj (2002). 軟體專案管理實踐. Addison-Wesley. ISBN 0201737213.