淺談軟體專案管理

標籤：比較   center   ace   tom   學習   十年   難度   err   strong   

  

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

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

1. 軟體過程式控制制

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

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

　　軟體組態管理(SCM)是指在開發過程中各階段，管理電腦程式演變的學科，它作為軟體工程的關鍵元素。已經成為軟體開發和維護的重要組成部分。SCM提供了結構化的、有序化的、產品化的管理軟體工程的方法。它涵蓋了軟體生命週期的所有領域並影響所有資料和過程。

1、軟體的品質需求

　　ISO 9001對品質的定義是"客戶要求的一種產品或服務所具備的所有特性"。從宏觀上來看，軟體品質的要求可分為：規定的和隱含的需求，規定的是指：使用者明確提出的需求和需要，而隱含的需求是指：需要開發人員自己來明確的基本的需求，例如：軟體的功能，軟體的使用周期等。ISO確定了六中軟體品質的特性：功能性，可靠性，可用性，有效性，可維護性，可移植性。

2、ISO軟體品質評價模型

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

1. 內部品質：在特定條件下時，軟體產品滿足需求能力的特性。主要指：在軟體開發的過程中的中間產品的品質
2. 外部品質：在已經達成一致的條件下使用時，軟體產品滿足使用者需求的程度；
3. 使用品質：在規定的使用條件下，軟體產品使特定使用者在達到規定目標方面的能力；

3、筆者的理解

　　如果將：軟體看作程式和軟體工程的集合體，那麼：軟體的品質就包括兩方面：

　　軟體的品質 = 程式的品質 + 軟體工程的品質^

　　程式的品質偏重於代碼的功能性實現，而軟體工程的品質則偏重於除去代碼本身的其他外界組成因素。

軟體工程的品質大致體現在以下幾個方面：

1. 軟體的開發成本(Cost)：

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

2. 軟體開發過程中的風險(Risk)：

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

3. 軟體各模組的品質(partial)

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

     

4、說說軟體測試的那些事(坑)？

   為什麼要做軟體測試？因為當我們規定了軟體品質的標準後，測試則是：軟體功能性需求是否得到滿足的有效體現，同時：在測試的過程中也有可能發現未知的bug,有助於程式員寫出更高品質的代碼~

   當然，也有一種聲音，諸如:Sriram Krishnan(一位在Yahoo和微軟工作過的程式員)在他的部落格中提到: 光看看一些從古至今最成功的軟體Team Dev就知道了。不論是當今的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，所以後期的維護與更新一定程度上也體現了軟體品質的提升。

  

5、關於軟體組態管理

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

　　軟體在組態管理中有4個主要的目標:

• 統一標識軟體配置項
• 管理一個或多個軟體配置項的變更
• 便於構造應用系統的不同版本
• 在配置隨時間演化的過程中，確保軟體的品質

    由此，定義了5個SCM任務：標識，版本控制、變更控制、組態稽核和報告。

  

　　標識配置項：利用物件導向的方法，對每個配置項進行標識，對軟體開發過程中的所有軟體項目賦予唯一的標識符，便於對其進行狀態控制和管理。

　　版本控制：儲存在開發過程中，相關資料項目的所有版本，便與軟體的開發與回退，避免出現：丟失版本或不知版本問題。感覺用github託管，會更加方便。

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

　　組態稽核和報告：變更控制的補充手段，來確保某一變更需求已被切實實現。組態稽核的任務便是驗證配置項對組態識別的一致性。組態稽核的實施是為了確保項目組態管理的有效性，體現組態管理的最根本要求，不允許出現任何混亂現象。

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

  

二、軟體的組織模式

軟體開發的主體——團隊

軟體工程的主體是人的活動，當一群有一定的集體目標的人聚集在一起為開發出具有一定功能的軟體而相互合作時，我們將其稱為團隊。團隊內部的成員，雖然相互合作但每個人有具體明確的分工。

  

• 團隊的模式：

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

    

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

      

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

    個人認為開放是泛型，可能是比較穩妥的一種開放方式，比封閉式稍具活性，又比隨機式更具有一定的約束性，但同時打破了同步式泛型的無交流，無約束的特點。

• 當下的團隊模式：

　　由於我們現在還沒有進入到實戰的模式(進行一個實際軟體的開發)，所以恰逢羅傑老師(另一個實戰的班級)，所以通過13級的學長們的博，總結下初步的感悟：

從極限編程說起：

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

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

什麼是結對程式設計？

  

    結對程式設計是指：一對程式員肩並肩、平等地、互補地進行開發工作。在現實生活中，也有這樣的例子：駕駛飛機（主駕駛和副駕駛）。所以這兩個人的具體工作分工為：

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

    2、另一個人負責導航，建議，維護。

    有一點需要注意：在結對程式設計的過程中：兩個人之間的角色要經常互換，避免長時間被人注視所導致的壓力和長時間的複審所引起的審"美"疲勞。

為什麼結對程式設計？

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

結對程式設計真的好嗎？

  在這裡說說筆者的看法：筆者是一個工作時相對獨立的人(不喜歡和認識的人坐在一起自習)，基於此種性格：結對程式設計尚有一定的難度係數。這種透明了程式員的全部工作細節與生活，在兩個不是很熟悉的情況下，需要有一段時間去磨合。此外，在雙方實力差距較大，或者基本不能有效溝通交流的情況下，效果不一定理想，如果"領航員"沒有發揮到自己的實際作用，那麼結對的意義便不大了。

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

另一種團隊: 敏捷開發

  

   敏捷開發的主要流程有：

   第一步：找出完成產品需要做的事情

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

第三步：衝刺

第四步：得到軟體的一個增量版本，發布給使用者。然後在此基礎上不斷的發布新功能

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

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

      

三、能力評估

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

   ISO9000.3是ISO9000品質體系認證中關於電腦軟體品質管理和品質保證標準部分。

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

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

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

筆者觀點：

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

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

　　軟體專案管理，軟體項目是為了達到目標，必須滿足真實的需要。從簡單的幾個方面對軟體專案管理進行介紹，還請諸君一閱~

  

  

  

  

參考文獻：

1. http://www.cnblogs.com/xinz/p/3857368.html現代軟體工程第十四章練習與討論
2. http://wiki.mbalib.com/wiki/%E8%BD%AF%E4%BB%B6%E9%85%8D%E7%BD%AE%E7%AE%A1%E7%90%86 軟體組態管理
3. http://www.cnblogs.com/jiel/p/4835963.html 2015年個人和團隊部落格地址
4. 鄒欣，現代軟體工程[M] 第二版,人民郵電出版社
5. Roger S.Pressman ，軟體工程實踐者的研究方法[M],機械工業出版社
6. Bob Hughes Mike Cotterell,軟體專案管理[M],機械工業出版社
7. http://baike.baidu.com/link?url=FHk0bzXE_F-TUgP-G7ReQ8fhlNWDihlkeaccjPWf2CZP-NZou5CwEnsj1zs92rsUwAmjZB-KtZvOqpDKqIy7f13Y4xbS8zyUd4lRi-9UFSjTPgDQSJrr4vIaQT8pTocznrZFDW-fPXI8b9M44Y_EnK 軟體品質保證

     

  

淺談軟體專案管理