軟體專案管理中可以看出分成兩部分:
專案是定義良好的任務,這是為了實現一個目標(例如,軟體開發和交付)進行的一些操作的集合。一個專案可以被描如何述為:
一個軟體專案是從需求收集到的測試和維護軟體開發的整個過程。在特定的時間段把它執行根據執行的方法以達到預期的軟體產品.
軟體被認為是一種無形的產品。軟體開發是一種在世界上所有的商業新流,有一個在建的軟體產品非常少的經驗。大多數軟體產品是量身客製化的,以滿足客戶的需求。最重要的是,底層的技術改變和前進如此頻繁和快速地一種產品的經驗可能不被施加到另一個。所有這樣的業務和環境的制約帶來的風險中的軟體開發,因此有必要有效地管理軟體專案.
上圖顯示了軟體專案的三重約束。它是軟體組織的重要組成部分,以提供高品質的產品,保持內客戶的預算約束的成本和按照預定的交付專案。有幾個因素,包括內部和外部,這可能會影響到這三重約束三角形。所有三個因素會嚴重影響其他兩個.
因此,軟體專案管理是必不可少把使用者的需求以及預算和時間的限制.
軟體專案經理是誰的人承擔執行軟體專案的責任。軟體專案經理是徹悟SDLC的各個階段,該軟體會通過的。專案經理可能不會直接參與生產的最終產品,但他控制和管理參與生產活動。.
專案經理密切監察發展過程中,準備和執行各種計劃,安排必要的和足夠的資源,保持所有團隊成員之間,以解決成本,預算,資源,時間,品質和客戶滿意度問題上的溝通。.
讓我們來看看一些責任,一個專案經理做 -
軟體專案管理包括了一系列活動,其中包括專案的規劃,確定軟體產品,在各個方面的估計成本,任務和事件的排程和資源管理的範圍。專案管理活動包括:
軟體專案計劃的任務,這是生產軟體的真正開始之前進行。這是那裡的軟體生產,但涉及與軟體生產任何方向的連線沒有具體的活動;相反,它是一組多個進程,這有利於軟體的生產。專案規劃可能包括以下內容:
它定義專案的範圍;這包括所有的活動過程中需要為了使可交付的軟體產品實現。範圍管理是必不可少的,因為它通過明確界定什麼專案可以做,什麼不可以做建立專案的界限。這使得專案以包含有限的,可量化的任務,它可以很容易地進行記錄,進而避免了成本和時間溢位.
在專案範圍管理,有必要 -
對於各項措施的有效管理準確的估計是必須的。有了正確的估計經理可以管理和更有效地控制專案。
專案估算可能涉及以下內容:
軟體大小可能無論是在KLOC(典千線)的條款或通過計算軟體的功能點數量進行估算。程式碼行數取決於編碼實踐和功能點,根據使用者或軟體的要求而有所不同.
管理人員估計在人員的要求,須出示該軟體工時方面的努力。對於工作量估算軟體規模應該知道。這可以通過管理者的經驗中得到,組織的歷史資料或軟體大小可以通過使用一些標準的公式轉換成工作
一旦尺寸和努力估計,需要對所生產的軟體的時間可被估計。需要努力分隔成子類別按要求的規格和軟體各組成部分的相互依存關係。軟體任務被劃分為更小的任務,活動或工作突破結構(WBS)的事件。在任務安排在一天到一天的基礎上,或在日曆月.
時間的總和,完成在幾小時或幾天內的所有任務所需的投資,以完成該專案的總時間.
這是因為它依賴於比任何以往的多個元件可能被認為是最困難的。估算專案成本時,需要考慮 -
我們討論了涉及工程估算各種引數,例如大小,精力,時間和成本.
專案經理可以評估使用兩種廣泛認可的技術所列出的因素 –
這種技術假設軟體的各種組合物的產物.
主要有兩種模式 -
程式碼估計行做代表 在軟體產品的程式碼行數.
功能點 估計是做代表的軟體產品功能點數量.
這種技術使用經驗匯出的公式來作出估計。這些公式是基於LOC或影格.
這種模式是由勞倫斯·普特南,它是基於諾頓的頻率分布(瑞利曲線)進行。普特南模型對映的時間和規模的軟體需要努力.
COCOMO代表建設性的成本模型,由巴里·W·貝姆發展。它把軟體產品分為三類軟體:有機,半獨立式和嵌入式。.
在專案工程排程指的是所有活動的路線圖,將與指定的順序,並在時隙分配給每項活動完成。專案經理往往傾向於定義各種任務和專案里程碑,並安排他們保持各方面的因素考慮。他們尋找的任務在於附表關鍵路徑,這是和(因為任務相互依賴性)嚴格分配的時間內要完成的具體方式。任務安排,在於出關鍵路徑都不太可能影響整個專案的所有計劃.
排程專案,有必要 -
用於開發軟體產品的所有元素都可以被假定為資源為該專案。這可能包括人力資源,生產工具和軟體庫.
該資源在組織作為資產池數量有限,並住宿提供。資源短缺阻礙專案的發展,它可以滯後的排程之後。分配額外資源增加,最終開發成本。因此,有必要估算,分配足夠的資源用於該專案.
資源管理包括 -
風險管理涉及的所有活動有關的識別,分析和決策提供專案中的可預見和不可預見的風險。風險可能包括以下內容:
有參與的風險管理流程如下活動:
識別 - 使所有可能的風險,這可能會發生在專案注釋.
群歸類 - 每對專案可能產生的影響進行分類的已知風險分為高,中,低風險的強度.
管理 - 在不同階段分析發生風險的概率。令計劃,以避免或面臨風險。盡量減少其副作用。.
監測 - 密切監測潛在的風險和他們的早期症狀。同時監測,以減輕或避免它們採取措施的效果。.
在這個階段中,在專案計劃中描述的任務根據它們的時間表執行.
執行需要以監視檢查按計劃一切是否會。監測觀察,檢查風險的可能性和採取措施,以解決風險或報告的各項任務的狀態.
這些措施包括 -
活動監控 - 定中的一些任務的所有活動,可以在一天到一天的基礎上進行監控。當在一個任務中的所有活動完成後,它被認為是完整的.
狀態報告- T該報告包含了一個星期給定的時間內完成,一般的活動和任務的狀態。狀態可以標記為已完成,或正在申請中的工作進展情況等.
里程碑清單 - 每個專案都被劃分成主要任務是執行(里程碑)基於SDLC的階段多個階段。這一具有里程碑意義的清單準備每隔數周,並報告里程碑的地位.
有效的溝通起著一個專案的成功至關重要的作用。它填補了空白用戶端和組織之間,團隊成員以及其他利益相關者在專案中,如硬體供應商之一.
通訊可以是口頭或書面的。通訊管理過程可具有以下步驟:
規劃 - 這一步包括所有的利益相關者在專案的鑑定和它們之間的溝通模式。它還認為,如果任何額外的通訊設施是必需的 .
共用 - 在確定規劃的各個方面,管理的重點是用正確的人在正確的時間分享的正確資訊。這樣可以使每一位參與該專案使用最新專案進展與現狀.
反饋 - 專案經理使用各種措施和反饋機制,建立狀態和效能報告。這種機制保證了各利益相關者的輸入來的專案經理為他們的反饋.
關閉 - -在每一個重大活動結束,SDLC或專案本身的結束一個階段的結束,封閉管理正式宣布,通過傳送電子郵件,通過分發的檔案或通過有效溝通等均值的硬拷貝來更新每個利益相關者 .
關閉後,球隊移動到下一個階段或專案.
組態管理是跟蹤和控制的要求,設計,功能和產品的開發方面的變化,軟體的處理.
IEEE將其定義為“識別和定義在系統中的專案,控制這些專案的整個生命週期的變化,記錄和報告的專案和變更請求的狀態,並驗證專案的完整性和正確性的過程”.
通常,一旦將SRS定稿有來自使用者的變化的需求的機會較少。如果它們發生,變化只涉及較高的管理的事先批准,因為有成本和時間的可能性溢位.
SDLC的階段是在假設,如果它的基準,即基線測量,定義了一個階段的完整性。 相位為基準,當有關它的一切活動都是成品,有據可查。如果它不是最後階段,它的輸出將在下一階段立即使用。 組態管理是組織管理,其中一個相位基準後,負責發生任何變化(過程中,要求的技術,戰略性等)的一門學科。 CM不斷檢查軟體進行任何.
組態管理是組織管理,其中一個相位基準後,負責發生任何變化(過程中,要求的技術,戰略性等)的一門學科。CM不斷檢查對軟體做任何改變.
變更控制的組態管理,從而確保軟體系統進行的所有更改都一致並按照組織的規章制度的作用。.
在產品組態的變化經過以下步驟 -
識別 - 無論從內部或外部源的改變請求到達。當更改請求正式確定,這是適當的記錄.
驗證 - 有效的變更請求的檢查及處理程式確認.
分析 - 變更請求的影響,進度,成本和所需的工作條件進行了分析。對系統的潛在變化的整體影響進行了分析.
控制 - 如果未來的變化既影響了太多的實體系統,或者是不可避免的,它是強制性的要高主管部門批准變更納入系統之前。如果變化是值得納入與否判定。如果不是的話,改變請求正式拒絕.
執行 - 如果前一階段確定執行的變更請求,這個階段採取適當的行動來執行的變化,做了徹底的修改,如果有必要的.
關閉要求 - 換作是正確實施驗證,並與系統的其餘部分合併。這在軟體新成立的改變記錄正常,請求正式關閉.
風險和不確定性增加了多方面的相對於該專案的大小,即使當專案是根據設定的方法開發的。.
有可用的工具,進行有效的專案管理,幫助。一些描述 -
甘特圖設計是由亨利·甘特(1917)。它表示相對於時間週期的專案進度。它是一種水平條形圖與代表定於專案活動的活動時間吧.
PERT(計劃評估和評審技術)圖是描述專案的網路圖的工具。它能夠以圖形方式表示專案的並行和連續的方式主要事件。事件,接二連三發生,顯示後面的事件的相關性較之一。
事件顯示為編號的節點。它們被標記的箭頭描繪了在專案任務的順序連線.
這是一個包含需要一段時間的專案活動(或相位)的資源欄或圖表表示數位(通常是技術熟練的員工)的圖形工具。資源直方圖是一種有效的工具,為員工規劃和協調。.
這個工具是在承認相互依存的任務,在專案有用。這也有助於找出最短路徑或關鍵路徑成功完成該專案。如PERT圖,每個事件被分配一個特定的時間框架。此工具顯示事件承擔事件的相關性可以進入下一只有前一個完成。.
事件按照其最早可能開始時間安排。開始和結束點之間的路徑是不能被進一步減小關鍵路徑和所有事件都需要在相同的順序來執行.