淺談軟件項目管理

時間 2019-11-29

標籤淺談軟件項目管理简体版

原文原文鏈接

　　初步接觸《軟件工程》這門專業課，在我看來：軟件工程是一個極具挑戰性的項目，在約定的時間內，整個項目小組能夠在知足用戶需求與軟件基本規範的狀況下，開發出穩定可靠的軟件。可是，在軟件開發的過程當中，每每有許多不可規避的風險與未知的狀況，例如：軟件不能按時交付，軟件的成本明顯超過預期，軟件未能達到用戶的需求等等，"若是所用的時間是預計時間的兩倍以上或費用超出預算兩倍以上的項目爲失控項目"，爲了有效規避項目在開發過程當中的風險，因此籠統來講，項目管理指的是：根據特定的規範，在預算的範圍內，按時完成指定的任務，運用高效快捷的方法，圍繞計劃對項目進行監控，在人力、費用和時間上進行控制。做爲Team16小組的組長，在整個軟件的開發過程當中，實際擔任的是"項目經理"的任務，因此下面讓咱們幾個小節來談談軟件項目管理。 html

　　軟件管理雖然涉及諸多的因素，例如：成本，質量，時間，資源等，但實際問題能夠歸結於：人員，問題和過程。當在軟件工程開發的過程當中，遇到了問題：須要人員之間的溝通與交流來進行解決，固然：人員是軟件工程開發中的核心力量。 git

1、軟件過程控制 程序員

　　在國際上，有這幾個通用的標準： github

　　軟件質量保證（SQA-Software Quality Assurance）是創建一套有計劃，有系統的方法，來向管理層保證擬定出的標準、步驟、實踐和方法可以正確地被全部項目所採用。軟件質量保證的目的是使軟件過程對於管理人員來講是可見的。ISO9000就是其中的一種，也就是產品的"說明書"。算法

　　軟件配置管理(SCM)是指在開發過程當中各階段，管理計算機程序演變的學科，它做爲軟件工程的關鍵元素。已經成爲軟件開發和維護的重要組成部分。SCM提供告終構化的、有序化的、產品化的管理軟件工程的方法。它涵蓋了軟件生命週期的全部領域並影響全部數據和過程。編程

一、軟件的質量需求 app

　　ISO 9001對質量的定義是"客戶要求的一種產品或服務所具有的全部特性"。從宏觀上來看，軟件質量的要求可分爲：規定的和隱含的需求，規定的是指：用戶明確提出的需求和須要，而隱含的需求是指：須要開發者本身來明確的基本的需求，例如：軟件的功能，軟件的使用週期等。ISO肯定了六中軟件質量的特性：功能性，可靠性，可用性，有效性，可維護性，可移植性。框架

二、ISO軟件質量評價模型 學習

　從1985年開始，國際標準化組織ISO和IEC就不斷地該改進軟件質量標準，現有的ISO質量標準，筆者以ISO/IEC 9126-1《產品質量-質量模型》，列出質量的三個方面：測試

　　內部質量：在特定條件下時，軟件產品知足需求能力的特性。主要指：在軟件開發的過程當中的中間產品的質量

　　　外部質量：在已經達成一致的條件下使用時，軟件產品知足用戶需求的程度；

　　　使用質量：在規定的使用條件下，軟件產品使特定用戶在達到規定目標方面的能力；

三、筆者的理解

　　若是將：軟件看做程序和軟件工程的集合體，那麼：軟件的質量就包括兩方面：

　　軟件的質量 = 程序的質量 + 軟件工程的質量

　　程序的質量偏重於代碼的功能性實現，而軟件工程的質量則偏重於除去代碼自己的其餘外界組成因素。

軟件工程的質量大體體如今如下幾個方面：

　　1.軟件的開發成本(Cost)

　　一個軟件在開發的過程當中，最主要的與實際相關的即是：人力與物力的消費。成本包括時間與金錢等，雖然古語有云"十年磨一劍"，但在現在高速發展的互聯網時代，用如此長的時間週期去開發一個軟件，顯然是烏托邦幻想的情節。

2.軟件開發過程當中的風險(Risk)

　　軟件開發實際是一我的與人之間的集體活動（以筆者的理解），每一個人都會負責相應的模塊與本身的責任，這就產生了人與人之間的關係，固然這些關係在特定的條件下，可能如同"級聯現象"同樣，被各類各樣的因素所影響；例如：項目成員的忽然退出(筆者就曾經遇到過這樣的狀況，結果項目組成員單我的的任務量就增多，同時項目的進度也受到影響)，開發過程沒有作很好的備份(固然如今許多軟件的開發都依託於github託管平臺，便於管理與控制)，開發難度過大(項目在開始的過程當中，一開始預期的實現效果因爲技術人和人的因素，而致使在預約的期限內沒法完成，歷史上：IBM 推出的System/360 Operating System就是一例)

　　3.軟件各模塊的質量(partial)

　　在軟件開發的過程當中，每每是分模塊來進行，任務會進行人員的劃分，在項目開發計劃的甘特圖(時間進度表)中，項目里程碑事件標誌着這個子模塊時間的結束，"千里之堤毀於蟻穴"，不妨以此類比，內部模塊的質量的好壞，里程碑事件的完成標準，項目各模塊之間的鏈接關係等小的事件每每會決定總體部分的質量。

四、說說軟件測試的那些事(坑)？

爲何要作軟件測試？由於當咱們規定了軟件質量的標準後，測試則是：軟件功能性需求是否獲得知足的有效體現，同時：在測試的過程當中也有可能發現未知的bug,有助於程序員寫出更高質量的代碼~

固然，也有一種聲音，諸如:Sriram Krishnan(一位在Yahoo和微軟工做過的程序員)在他的博客中提到: 光看看一些從古至今最成功的軟件開發團隊就知道了。不管是當今的Facebook，仍是30年前最初的NT團隊，不少偉大的產品都是出自沒有或不多測試人員的團隊。

可是，這個事情應該一分爲二的來看:你不得不認可在現實生活中的確有不少大牛,人家的代碼健壯性很強，讓你根本就找不到什麼bug(不過，通過面向對象OO這門課，你們的代碼質量都提高了不少)，可是:另外一方面，你的軟件沒有通過充分的測試，就推出產品，那麼當用戶不斷地在使用過程當中發現各類各樣的問題是，想必用戶的好感度會大大下降,不過如今不少手機app，用戶與後臺開發人員交互地不少，例如：meizu手機所推出的系統專門有一個模塊：用戶幫助(手機用戶能夠進行bug的反饋，而且會有工程師來答覆，筆者就曾經反饋過bug而且收到了回覆)，同理：像新浪微博裏的微博小祕書也具有這個特色。

軟件測試坑點1

　　誰來測試？是這段程序代碼的開發人員仍是有專門的測試人員？若是是開發人員想要繼續新的功能而不想測試或是專門的測試人員來作，他是否能理解代碼的所有的功能意圖？開發人員在得知代碼有人來測試還對這段代碼負責嗎？

軟件測試坑點2

　　測試過程當中，測試方法的選擇與用例的多少？在咱們OO這門課中，一次的做業是編寫測試用例，使得分支的覆蓋率達到100%，因爲當時本身的代碼規模寫的比較大，因此寫完全部的測試用例並非一件輕鬆的事情，那麼：在軟件開發的過程當中，測試的用例恐怕就不是和筆者的做業一個數量級，那麼測試數量如何保證，自動化測試的方法雖然可取但可能存在必定的侷限性，John Musa(曾在 AT&T Bell實驗室工做)提出：經過評價每一個模塊可能使用次數來下降故障率。越是經常使用的組件越要嚴格測試。這種提議尚可考慮。

軟件測試坑點3

　　發現bug時的採起措施？一個bug的出現可能隱藏着潛在未知的問題，由於：即便在你充分下降各模塊的耦合程度下，各部分之間仍是存在必定的相關性，在這樣的狀況下，極有可能發生多米諾骨牌效應，當發現問題時，是否應當從新測試全部樣例？固然並不可取，一種一種基於估算錯誤的方法能夠參考( 參見Tom Gilb的《Software Metrics》)。

筆者的觀點：

　　一個好的軟件項目背後必定是開發人員和測試人員的共同努力，依據不一樣的軟件項目估摸採起不一樣的質量標準和測試方法，另外一方面：軟件質量應該是一個不斷提高迭代的過程，如今市面上的軟件都不斷地推出更新包，實質也是在解決軟件使用中的bug，因此後期的維護與更新必定程度上也體現了軟件質量的提高。

五、關於軟件配置管理

　　定義：軟件配置管理(SCM) 是在整個軟件工程中應用的一種普適性活動，在卡發的過程當中，變動隨時會發生，SCM活動主要應用於:標識變動、控制變動、保證恰當的實施變動、向有關人員報告變動。

　　軟件在配置管理中有4個主要的目標:

統一標識軟件配置項
管理一個或多個軟件配置項的變動
便於構造應用系統的不一樣版本
在配置隨時間演化的過程當中，確保軟件的質量

由此，定義了5個SCM任務：標識，版本控制、變動控制、配置審覈和報告。

　　　標識配置項：利用面向對象的方法，對每一個配置項進行標識，對軟件開發過程當中的全部軟件項目賦予惟一的標識符，便於對其進行狀態控制和管理。

　　　版本控制：存儲在開發過程當中，相關數據項的全部版本，便與軟件的開發與回退，避免出現：丟失版本或不知版本問題。感受用github託管，會更加方便。

　　　變動控制：經過對變動申請人的變動請求進行評估，造成變動報告，創建工程變動單(ECO),對變動進行實施，同時：創建適當的版本與記錄。

　 配置審覈和報告：變動控制的補充手段，來確保某一變動需求已被切實實現。配置審覈的任務即是驗證配置項對配置標識的一致性。配置審覈的實施是爲了確保項目配置管理的有效性，體現配置管理的最根　本要求，不容許出現任何混亂現象。

筆者看來，配置管理：實際是對軟件開發過程當中是否進行變動進行評估，對執行的變動進行記錄使其變得有條理化與邏輯性，進行有序的變動控制，

二、軟件的組織模式

軟件開發的主體——團隊

軟件工程的主體是人的活動，當一羣有必定的集體目標的人彙集在一塊兒爲開發出具備必定功能的軟件而相互合做時，咱們將其稱爲團隊。團隊內部的成員，雖然相互合做但每一個人有具體明確的分工。

　　傳統團隊的模式：

　　傳統的團隊的模式，由Constantine［CON93］提出的四種"組織範型"，以下表。

團隊類型	具體特徵
封閉式範型	按照傳統的權利層次來組織小組。這種小組在開發與過去已經作過的產品相似的軟件時十分有效，但在這種封閉式範型下難以進行創新式的工做
隨機式範型	鬆散地組織小組，並依賴於小組成員我的的主動性。當須要創新或技術上的突破時，按照這種隨機式範型組織的小組頗有優點。但當須要"有次序的執行"才能完成工做時，這種小組組織範型就會陷入困境。
開放式範型	試圖以一種，既具備封閉式範型的控制性，又包含隨機式範型的創新性的方式來組織小組。工做的執行結合了大量的通訊和基於小組一致意見的決策。開放式範型小組結構特別適於解決複雜問題，但可能不象其餘類型小組那麼效率高
同步式範型	賴於問題的天然劃分，組織小組成員各自解決問題的片段，他們之間沒有什麼主動的通訊須要

首先："封閉式範型"更相似於官僚模式，人與人之間存在着：明顯的階級關係，這種方式更像咱們在平時上班中的工做關係，你的行爲必然會受到你的頂頭上司的約束，雖然規則性和秩序性變得更好，但在這種模式下，很容易變成"老闆驅動"的工做模型。

　　我的認爲開放式泛型，多是比較穩妥的一種開放方式，比封閉式稍具活性，又比隨機式更具備必定的約束性，但同時打破了同步式泛型的無交流，無約束的特色。

　　當下的團隊模式：

　　因爲咱們如今尚未進入到實戰的模式(進行一個實際軟件的開發)，因此恰逢羅傑老師(另外一個實戰的班級)，因此經過13級的學長們的博文，總結下初步的感悟：

　　從極限編程提及：

極限編程(eXtreme Programming,XP)：在傳統的開發過程當中，增進溝通和交流的典型方式是經過文檔，但XP的提倡者們建議用比較隨意的交流和溝通方式。不編寫單獨的文檔，反之增強關鍵的軟件產品(例如軟件代碼和測試數據)。

在代碼複審(就是讓別人來看本身的代碼，是否在"代碼規範"的框架內正確解決了問題)，經過此點，能夠發現：在邏輯、算法、潛在和迴歸性的錯誤的基礎上，互相傳授經驗，在瞭解別人代碼的基礎上也不斷提升本身的能級，而代碼複審便是極限編程中的一個重要的觀點，下面，引出咱們的"重頭戲"——結對編程。

　　什麼是結對編程？

結對編程是指：一對程序員肩並肩、平等地、互補地進行開發工做。在現實生活中，也有這樣的例子：駕駛飛機（主駕駛和副駕駛）。因此這兩我的的具體工做分工爲：

一、"主駕駛"負責具體任務的執行(駕駛飛機，編寫程序)。

二、另外一我的負責導航，建議，維護。

有一點須要注意：在結對編程的過程當中：兩我的之間的角色要常常互換，避免長時間被人注視所致使的壓力和長時間的複審所引發的審"美"疲勞。

　　爲何結對編程？

結對編程：就是把後期的軟件測試和軟件複審的工做挪到了在代碼編寫時，就同步的進行不間斷地複審。而好處能夠這樣理解：讓別人在代碼已近完工的狀況下，再去作代碼的測試還不如：在代碼的編寫階段進行代碼可行性和邏輯正確性的檢查，一方面：這樣的代碼是兩我的中能力較好的完成品(固然是結對編程人員的心血與結晶)，另外一方面：結對編程有助於：在互相討論，互相合做的基礎上進行編碼，尤爲獅是在遇到問題時：能夠一塊兒解決，有助於提升效率和互相學習；

　　結對編程真的好嗎？

在這裏說說筆者的見解：筆者是一個工做時相對獨立的人(不喜歡和認識的人坐在一塊兒自習)，基於此種性格：結對編程尚有必定的難度係數。這種透明瞭程序員的所有工做細節與生活方式，在兩個不是很熟悉的狀況下，須要有一段時間去磨合。此外，在雙方實力差距較大，或者基本不能有效的溝通交流的狀況下，效果不必定理想，若是"領航員"沒有發揮到本身的實際做用，那麼結對的意義便不大了。

結對編程在現實中，不少大型IT都是兩我的合做開始的，例如:Jerry Yang & David (Yahoo! 創始人),何況:從某種意義上，：結對合做也是團隊合做的基礎,更爲重要的是：結對過程當中，兩我的之間是平等的關係，交流與反饋，是結對編程的核心吧！(話說：我這學期好像是和某我的在結對編程哎：怎麼才發現)

　　另外一種團隊: 敏捷開發

敏捷開發的主要流程有：

第一步：找出完成產品須要作的事情

第二步：決定當前衝刺要解決的事情

　　　第三步：衝刺

　　　第四步：獲得軟件的一個增量版本，發佈給用戶。而後在此基礎上不斷的發佈新功能

敏捷團隊的主要特色有：自主管理(本身不斷反思並改進不足)，自我組織(在本身事情作完後，幫助其餘人)，多功能型（負責多項工做）

能夠看到：敏捷團隊適用於CMM層次比較高的團隊，是一種對開發技術人員更高層次的要求。

3、能力評估

軟件過程能力描述了一個開發組織開發軟件開發高質量軟件產品的能力，此過程能力包括可以達到的質量、效率、工期、成本等。現行的國際標準主要有兩個：ISO9000.3和CMM。

ISO9000.3是ISO9000質量體系認證中關於計算機軟件質量管理和質量保證標準部分。

CMM（能力成熟度模型）是美國卡納基梅隆大學軟件工程研究所（CMU/SEI）於1987年提出的評估和指導軟件研發項目管理的一系列方法，用5個不斷進化的層次來描述軟件過程能力。

ISO9000和CMM的共同點是兩者都強調了軟件產品的質量。所不一樣的是，ISO9000強調的是衡量的準則，但沒有告訴軟件開發人員如何達到好的目標，如何避免差錯。CMM則提供了一整套完善的軟件研發項目管理的方法。它可告訴軟件開發組織，若是要在原有的水平上提升一個等級，應該關注哪些問題，而這正是改進軟件過程的工做。

CMM描述了五個級別的軟件過程成熟度（初始級，可重複級，已定義級，已定量管理級，優化級），成熟度反映了軟件過程能力的大小。

筆者觀點：

軟件過程能力更多的說的是：軟件的開發能力和軟件的質量，質量方面已在上文討論過，而開發能力更多的與團隊中人員的因素有關，一個團隊中人的能力。

一個團隊中不能僅僅由於：一我的的工做量的多少，或是工做時間的長短，或是一我的職位的高低，這些評估方法都欠妥。一種比較好的方法，是利用兩個維度完成任務的等級與貢獻率)來綜合評價，獲得一個較爲中和的結果。我的認爲CMM的級別體系是一個不斷上升，演化的階段。

　　軟件項目管理，軟件項目是爲了達到目標，必須知足真實的須要。本博文從簡單的幾個方面對軟件項目管理進行介紹，還請諸君一閱~，資歷尚淺，還請多多指教！

參考文獻：