軟體專案管理

從事軟體開發的IT公司的職位模式可以分為兩部分

軟體建立
軟體專案管理

專案是一個明確定義的任務，它是由若干操作按順序執行以實現目標的集合（例如，軟體開發和交付）。專案可以描述為：

每個專案可能都有一個獨特且不同的目標。
專案不是例行活動或日常運營。
專案有開始時間和結束時間。
專案在其目標實現後結束，因此它是組織生命週期中的一個臨時階段。
專案需要充足的資源，包括時間、人力、資金、材料和知識庫。

軟體專案

軟體專案是軟體開發的完整過程，從需求收集到測試和維護，根據執行方法，在規定的時間內完成以實現預期的軟體產品。

軟體專案管理的必要性

軟體被稱為無形產品。軟體開發是世界商業中一種全新的潮流，在構建軟體產品方面經驗很少。大多數軟體產品都是定製的，以滿足客戶的需求。最重要的是，底層技術變化和進步如此頻繁和迅速，以至於一個產品的經驗可能無法應用於另一個產品。所有這些業務和環境限制都會給軟體開發帶來風險，因此有效地管理軟體專案至關重要。

上圖顯示了軟體專案的三重約束。對於軟體組織來說，在保持成本在客戶預算限制內的同時，按計劃交付高質量的產品是至關重要的。有幾個內部和外部因素可能會影響這個三重約束三角形。任何三個因素中的一個都可能嚴重影響其他兩個因素。

因此，軟體專案管理對於結合使用者需求以及預算和時間限制至關重要。

軟體專案經理

軟體專案經理是一個承擔執行軟體專案責任的人。軟體專案經理充分了解軟體將經歷的SDLC的所有階段。專案經理可能從未直接參與最終產品的生產，但他控制和管理生產中涉及的活動。

專案經理密切監控開發過程，準備和執行各種計劃，安排必要的和充足的資源，維護所有團隊成員之間的溝通，以解決成本、預算、資源、時間、質量和客戶滿意度的問題。

讓我們看看專案經理肩負的一些職責 -

人員管理

擔任專案領導
與利益相關者聯絡
管理人力資源
建立彙報等級等。

專案管理

定義和設定專案範圍
管理專案管理活動
監控進度和績效
每個階段的風險分析
採取必要的步驟來避免或解決問題
擔任專案發言人

軟體管理活動

軟體專案管理包括許多活動，其中包括專案規劃、確定軟體產品的範圍、估算各種方面的成本、任務和事件的排程以及資源管理。專案管理活動可能包括：

專案規劃
範圍管理
專案估算

專案規劃

軟體專案規劃是在軟體實際生產開始之前執行的任務。它為軟體生產服務，但不涉及任何與軟體生產有直接聯絡的具體活動；而是一組促進軟體生產的多個過程。專案規劃可能包括以下內容：

範圍管理

它定義專案的範圍；這包括為了製作可交付的軟體產品而需要完成的所有活動和流程。範圍管理至關重要，因為它透過明確定義專案中將完成哪些工作以及不完成哪些工作來建立專案的邊界。這使得專案包含有限且可量化的任務，這些任務可以輕鬆記錄，從而避免成本和時間超支。

在專案範圍管理期間，有必要 -

定義範圍
決定其驗證和控制
將專案分解成多個較小的部分，以便於管理。
驗證範圍
透過合併對範圍的更改來控制範圍

專案估算

為了有效管理，準確估算各種指標是必須的。透過正確的估算，管理人員可以更有效地管理和控制專案。

專案估算可能包括以下內容：

軟體規模估算
軟體規模可以用KLOC（千行程式碼）來估算，也可以透過計算軟體中的功能點來估算。程式碼行數取決於編碼實踐，功能點根據使用者或軟體需求而變化。
工作量估算
管理人員根據生產軟體所需的人員需求和工時來估算工作量。對於工作量估算，應該知道軟體規模。這可以透過管理人員的經驗、組織的歷史資料獲得，或者可以使用一些標準公式將軟體規模轉換為工作量。
時間估算
一旦估算出規模和工作量，就可以估算出生產軟體所需的時間。根據需求規範和軟體各個元件的相互依賴性，將所需的工作量細分為子類別。軟體任務透過工作分解結構 (WBS) 分解成更小的任務、活動或事件。任務按天或日曆月安排。

完成所有任務所需時間的總和（以小時或天為單位）是完成專案所需的總時間。
成本估算
這可能是所有估算中最困難的，因為它依賴於比任何先前因素更多的元素。為了估算專案成本，需要考慮 -

軟體規模
軟體質量
硬體
額外的軟體或工具、許可證等。
具有特定任務技能的熟練人員
差旅費用
溝通
培訓和支援

專案估算技術

我們討論了專案估算中涉及的各種引數，例如規模、工作量、時間和成本。

專案經理可以使用兩種廣為認可的技術來估算上述因素 -

分解技術

這種技術將軟體視為各種成分的產物。

主要有兩個模型 -

程式碼行數估算基於軟體產品中的程式碼行數。
功能點估算基於軟體產品中的功能點數。

經驗估算技術

此技術使用經驗得出的公式進行估算。這些公式基於LOC或FP。

普特南模型
此模型由勞倫斯·H·普特南建立，基於諾登的頻率分佈（瑞利曲線）。普特南模型將所需的時間和工作量與軟體規模對應起來。
COCOMO
COCOMO代表建設性成本模型，由Barry W. Boehm開發。它將軟體產品分為三類軟體：有機型、半獨立型和嵌入型。

專案進度安排

專案進度安排是指所有活動的路線圖，這些活動需要以指定的順序並在分配給每個活動的時段內完成。專案經理傾向於定義各種任務和專案里程碑，並考慮到各種因素來安排它們。他們尋找計劃中關鍵路徑上的任務，這些任務需要以特定方式（由於任務相互依賴）並在分配的時間內嚴格完成。安排關鍵路徑之外的任務不太可能影響專案的整體進度。

為了安排專案，有必要 -

將專案任務分解成更小、更易於管理的形式
找出各種任務並關聯它們
估算每個任務所需的時間範圍
將時間劃分為工作單元
為每個任務分配足夠數量的工作單元
計算從專案開始到結束所需的總時間

資源管理

用於開發軟體產品的所有元素都可以被認為是該專案的資源。這可能包括人力資源、生產工具和軟體庫。

資源的數量有限，並作為資產池保留在組織中。資源短缺會阻礙專案的開發，並可能落後於進度。分配額外的資源最終會增加開發成本。因此，有必要估算和分配專案所需的充足資源。

資源管理包括 -

透過建立專案團隊並將責任分配給每個團隊成員來定義合適的組織專案
確定特定階段所需的資源及其可用性
在需要資源時生成資源請求，並在不再需要時取消分配資源。

專案風險管理

風險管理包括所有與識別、分析和為專案中可預測和不可預測的風險做準備的活動。風險可能包括以下內容：

經驗豐富的員工離開專案，新的員工加入。
組織管理的變化。
需求變更或誤解需求。
低估所需的時間和資源。
技術變化、環境變化、商業競爭。

風險管理流程

風險管理流程中涉及以下活動：

識別 - 記錄專案中可能發生的所有風險。
分類 - 根據已知風險對專案可能造成的潛在影響，將其分類為高、中和低風險強度。
管理 - 分析風險在各個階段發生的機率。制定規避或應對風險的計劃。努力將風險的負面影響降到最低。
監控 - 密切監控潛在風險及其早期徵兆。同時監控為減輕或避免風險而採取的措施的效果。

專案執行與監控

在此階段，專案計劃中描述的任務將按照其進度執行。

執行需要監控，以檢查一切是否按照計劃進行。監控是指觀察以檢查風險的機率，並採取措施來解決風險或報告各種任務的狀態。

這些措施包括 -

活動監控 - 可以對任務中安排的所有活動進行每日監控。當任務中的所有活動都完成後，則認為該任務已完成。
狀態報告 - 報告包含在給定時間段（通常為一週）內完成的活動和任務的狀態。狀態可以標記為已完成、待定或進行中等等。
里程碑檢查表 - 每個專案都細分為多個階段，在這些階段中根據SDLC的階段執行主要任務（里程碑）。此里程碑檢查表每隔幾周準備一次，並報告里程碑的狀態。

專案溝通管理

有效的溝通在專案的成功中起著至關重要的作用。它彌合了客戶與組織之間、團隊成員之間以及專案中的其他利益相關者（例如硬體供應商）之間的差距。

溝通可以是口頭的或書面的。溝通管理過程可能包括以下步驟

計劃 - 此步驟包括識別專案中的所有利益相關者以及他們之間的溝通方式。它還考慮是否需要任何額外的溝通設施。
共享 - 在確定計劃的各個方面之後，管理者專注於在正確的時間與正確的人分享正確的資訊。這使每個參與專案的人都瞭解專案的進度及其狀態。
反饋 - 專案經理使用各種措施和反饋機制，並建立狀態和績效報告。此機制確保來自各個利益相關者的投入作為他們的反饋傳達給專案經理。
結束 - 在每個重大事件結束、SDLC階段結束或專案本身結束時，將正式宣佈管理結束，透過傳送電子郵件、分發文件的硬複製或其他有效的溝通方式來更新每個利益相關者。

結束之後，團隊將轉入下一階段或專案。

配置管理

配置管理是一個跟蹤和控制軟體變化的過程，這些變化涉及產品的需求、設計、功能和開發。

IEEE將其定義為“識別和定義系統中的專案，控制這些專案在其整個生命週期中的變化，記錄和報告專案和變更請求的狀態，以及驗證專案的完整性和正確性的過程”。

通常，一旦SRS最終確定，使用者就很少需要更改需求。如果發生更改，則只有在獲得高階管理層的批准後才能處理這些更改，因為這可能會導致成本和時間的超支。

基線

如果某個SDLC階段已建立基線，則認為該階段已結束，即基線是定義階段完整性的度量。當與某個階段相關的所有活動都已完成並有良好文件記錄時，該階段就已建立基線。如果它不是最終階段，則其輸出將用於下一個直接階段。

配置管理是組織管理的一門學科，它負責處理在階段建立基線後發生的任何變化（流程、需求、技術、策略等）。CM會檢查軟體中所做的任何更改。

變更控制

變更控制是配置管理的功能，它確保對軟體系統進行的所有更改都是一致的，並且符合組織的規則和規章。

產品配置的更改將經歷以下步驟 -

識別 - 變更請求來自內部或外部來源。當正式識別變更請求時，會對其進行適當的記錄。
驗證 - 檢查變更請求的有效性並確認其處理程式。
分析 - 就進度、成本和所需工作量而言，分析變更請求的影響。分析預期的更改對系統的整體影響。
控制 - 如果預期的更改會影響系統中的許多實體，或者它是不可避免的，則必須在將更改納入系統之前獲得高階管理人員的批准。確定更改是否值得納入。如果不是，則正式拒絕變更請求。
執行 - 如果上一階段決定執行變更請求，則此階段將採取適當的措施來執行更改，如有必要，將進行徹底的修訂。
關閉請求 - 驗證更改是否已正確實施並與系統的其餘部分合並。軟體中新合併的更改將被妥善記錄，並且請求將被正式關閉。