敏捷的項目管理范文
時間：2023-09-20 16:57:36
導語：如何才能寫好一篇敏捷的項目管理，這就需要搜集整理更多的資料和文獻，歡迎閱讀由公務員之家整理的十篇范文，供你借鑒。
篇1
【關鍵詞】敏捷開發 瀑布模型 產品開發項目
在日益激烈的全球競爭中，知識創新能力是影響企業核心競爭力的關鍵因素之一，而作為知識創新的公司通常都以產品開發作為主營業務，其中大型公司畢竟是少數，絕大多數都是中小型公司，必須有一種可以嚴格質量把關，并且高效率的開發管理方法，才能適應市場的變化。
針對產品開發項目管理方法的問題，眾多公司及學者提出了諸多解決方法如：IBM公司的IPD產品集成開發流程[1]，國際流行的CMM管理體系[2]，新型的敏捷開發模型[3]等都被一些公司采用為基本的產品項目開發方法。
目前，IPD及CMM這種瀑布開發及管理模型要求公司資金充足，職能明確，市場定位超前，并引領并控制市場。這些方法在大型公司，或國外成熟的市場環境下運行的十分完善。但在我國不具備這種良好的市場環境，絕大多數中小公司不具備充足的資金及良好的市場定位，處于一種不斷應付市場需求變化的情況下。因此，需要一種能夠快速適應需求的項目管理方法。敏捷開發的出現完成了以軟件開發為基礎公司的項目運作方式，它們快速的跟蹤需求。但是產品開發往往面臨著軟件與硬件的結合，產品的硬件及架構的變動帶來了巨大的成本消耗。所以即要能夠應付過多的變化帶來的成本問題，又要快速的響應市場需求是產品開發項目管理的根本問題。
本文借鑒了瀑布的嚴謹質量控制的方法可敏捷開發快速適應需求變化的理論，總結了較為實用的中小型企業產品開發項目管理方法。
1 瀑布模型和敏捷開發模型
2.1 瀑布模型原理
瀑布模型（Waterfall Model） 是一個項目開發架構，開發過程是通過設計一系列階段順序展開的，從系統需求分析開始直到產品和維護，每個階段都會產生循環反饋，因此，如果有信息未被覆蓋或者發現了問題，那么最好 “返回”上一個階段并進行適當的修改，項目開發進程從一個階段“流動”到下一個階段，這也是瀑布模型名稱的由來。瀑布模型要求每個階段都要為下一階段提供依據，否則將不得向下進行。這也是瀑布模型的優點，也是它的缺點。
2.2 敏捷開發
敏捷開發是一種以人為核心、迭代、循序漸進的開發方法。在敏捷開發中，軟件項目的構建被切分成多個子項目，各個子項目的成果都經過測試，具備集成和可運行的特征。換言之，就是把一個大項目分為多個相互聯系，但也可獨立運行的小項目，并分別完成，在此過程中軟件一直處于可使用狀態。主要的實現方法有XP（極限編程）、Scrum模型等。
3 產品開發瀑布與敏捷結合方法
3.1 問題的提出
即然中小型公司的產品開發過程單純的執行某種特定的模型都會帶來一定的問題，那么是否可以將二者結合呢？經過研究和實際應用發現，結論就可行的。
3.2 結合方法的計劃制作
計劃的制作是任何項目最重要的開端，從計劃制作開始就將體現結合方法的與眾不同及其可操作性。
首先計劃中要把概念階段和規劃階段列入（在某些時候可以被稱作需求階段和概要設計階段），對于產品開發面臨的硬件設備迭代周期長，無法在后期快速響應需求變化，這兩個階段是一定要開展的。這兩部分結束后所達成的目標只有一個，那就是確定下方案，特別就硬件方案。為后期的敏捷打好堅實的基礎。（注：上圖在實際運行時需求根據情況進行分解和修改）
3.3 概念階段和規劃階段的瀑布模型
概念階段和規劃階段與IPD幾乎沒有什么變化，對于中小型公司可以嚴格的執行各個階段，也可以簡化每一步的完善程度（注：每一步都要執行），每一步都向著硬件電路方案的確定而努力，軟件固件進行配合方案設計，這兩個階段結束后，與硬件設計方案有關的需求都最終確定。例如：某些產品需要用串口通信，對于此時只需要把要用幾個串口，速度要求多少即可，對于通信協議暫時可以忽略不計。
3.4 設計驗證階段
在設計驗證階段就可以主要發揮敏捷開發的優勢，由于在上兩個階段中硬件方案已經確定，所以硬件還是需要一步一步的按照瀑布進行，設計，制版，焊接，調試。此時軟件和固件按瀑布方式進行平臺的搭建，為敏捷的迭代過程做準備。當硬件人員由相關軟件及固件人員配合將硬件設備調試通過之后，交由軟件及固件人員（固件包括了FPGA等硬件邏輯代碼工作）聯合開發，此時以每一個星期或兩個星期為一次迭代，每次迭代重新討論需求變更及本迭代期內所要完成的功能需求。從現在開始的調試，測試及需求變換完全可以以敏捷開發方式進行。此時需要產品經理或項目經理根據最終的時間來迭代調整需求及優先級直到項目結束。
4 結論
本文在介紹了在瀑布模型及敏捷開發模型的基礎上，綜合分析了目前中小型企業產品項目開發中中遇到的問題，就建立完善、可操作、動態靈活的項目開發管理方法提出了建議，并采用實際的操作方法及實例充分表明本文設計方法的正確可行。
參考文獻
[1]朱瑞萍.IPD―一種集成的產品開發模式[J].市場研究，2003（12）.
[2]高琰，李建華等.基于CMM的軟件項目管理系統的設計與實現[J].計算機工程，2002（9）.
[3]俞定國.敏捷方法在企業應用系統開發中的應用與改進[J].微計算機應用，2005（26）.
篇2
關鍵詞 民航石油庫 項目管理 消防工程
機場油庫是機場建設的重要配套工程，是構建航油供應網絡的重點項目，民航油庫的設計及項目管理應遵循《石油庫設計規范》、《民航機場供油工程規范》等國家標準進行設計及施工，其中的消防安全設計和管理要達到《石油化工企業設計防火規范》的有關規定。同其他建筑工程施工一樣，油庫工程也是一項多工種、多專業的系統工程，要使施工全過程順利進行，以期達到預定的目標，就必須用科學的方法進行實施管理。施工中加強現場項目的管理尤其重要，本文以消防工程為重點談談對此的看法。
1項目管理的一般步驟和實施過程
油庫工程油庫而言，其直接控制的目標有三個：投資、進度、質量。即在保證安全的前提下，按計劃的投資、進度、質量完成項目目標。這三個目標彼此之間是對立統一的關系，難以同時達到最優，其實施應以項目整體最優為目標。優化工程現場管理是指運用系統的觀點、理論和方法，對工程現場的計劃、組織、控制、協調等進行全面管理的過程。優化現場管理的主要內容可分為施工作業管理、施工質量管理和現場整體管理。具體表現為： 1）把好設計審查關，及早解決設計中錯漏問題和施工中可能遇到的困難，盡可能避免或減少工程變更。如儲罐之間安全間距、消防通道的設計都要仔細審查合格，方可施工。2）嚴格把好材料、設備質量關。杜絕劣質材料或不合格材料在施工中使用，確保工程的內在質量。3）嚴格監督檢查施工工序質量。嚴格監控施工過程，不符合要求的及時督促施工方整改?？刂坪霉ば蛸|量，確保工程質量。特別是管道施工質量問題因比較隱蔽需要嚴格加以控制，對管道施工人員除持證外應有一定的經驗和熟練程度，以免為日后留下安全隱患。4）組織好工程例會。定期召開工程例會，交流施工情況，檢查工程質量、進度、投資控制情況，處理存在問題，安排下期工作。5）把好工程費用關。作好工程計量，防止高估算和重復計量。與審計機構密切合作，做好工程預算和實施階段的內部審計，嚴格審核預結算，爭取最大程度的核減工程費用，為工程節約資金。
其中作為重中之中的工作有二：一是施工過程中的安全管理，如施工單位的資質審查，施工合同中的安全條款和簽定。對施工過程中的用火、高空作業的安全管理等不能有絲毫放松。二是對系統調試、驗收階段發現的問題應加以重視，切不可因為工程將要完工要加以忽略。下面以消防工程的項目管理加以說明。
2消防工程的項目管理
2.1消防工程的項目管理內容
2.1。1 范圍管理
消防工程是建設項目中的一個分部工程，與其他分部工程如主體結構、給水排水、采暖、建筑電氣、電梯等又有有機聯系。主要包括：火災自動報警系統（裝置）、自動噴水滅火系統、防排煙系統、消火栓系統、、氣體滅火系統（裝置）、消防聯動系統、消防電梯、應急照明和疏散系統等。
2.1。2 時間管理
消防工程大部分是在主體工程土建完工后進場，需要在與其他工種的協調配合下，通過高效率的計劃、組織、指導和控制的手段，在時間上達到預定目標。
2.1。3 費用管理
在滿足設計要求的前提下，通過項目管理，運用經濟的方法在費用控制上達到預定目標。
2.1。4 質量管理
消防工程是構成建設工程的基本單元，因其專業要求嚴和技術含量大而直接關系到整個建筑物體的消防安全，關系到防火滅火的成敗。因此質量管理非同尋常、至關重要，必須給予極大的關注。
2.2、消防工程項目的生命周期和建設程序
按照建筑階段一般劃分方法，消防工程項目與所有建設工程項目一樣，有5個階段，即決策階段、設計階段、招投標階段、施工階段、竣工驗收階段。
按照我國建設程序，消防工程的生命周期包括項目建議書、可行性研究、設計工作、建設準備、建設實施、竣工驗收交付使用6個階段。在以上階段中應注意以下要求：
1）消防工程的設計與總體工程一起設計，設計單位應具有相應的資質；
2）在初設和施工圖設計等過程中均須按照國家工程建設消防技術標準強制性要求進行設計工作，施工圖設計要在取得《建設工程消防設計審核意見書》同意或建設工程消防設計備案合格后才能施工；
3）消防工程的施工單位須取得省級建設主管部門發給的消防工程施工資質證書；
4）消防工程施工單位的主要技術人員除要有相應職稱外，所有施工人員須持證上崗；
5）施工中如需變動消防設計，須取得原先審核的消防機構書面同意或重新備案；
6）在工程竣工后，消防工程要有具有資質的檢測單位進行檢測，出具合格報告后，交消防機構備案；
7）消防工程要在該建設工程取得《建設工程消防驗收意見書》合格或建設工程消防驗收備案合格后才能投入使用；
8）消防工程在交付使用后，對管理人員和操作人員要進行培訓，通過有效管理才能正常運行。
2.3、淺談消防工程項目的質量控制
2.3.1設計階段的質量控制
設計單位應具有相應設計資質，設計人員要求具有較高的理論水平，充分理解和掌握國家有關消防技術規范，特別是要嚴格執行國家工程建設消防技術標準強制性要求。設計單位和設計人員不能為了迎合業主要求，擅自降低設計標準，從而降低消防施工質量。
2.3.2 施工準備階段的質量控制
在這個階段施工單位應做好圖紙自審工作， 找出圖紙設計中存在的影響今后施工、驗收和使用的隱患。在建設單位組織的圖紙會審中， 將自審中發現的問題提出， 經各方商討后形成書面紀要， 作為施工與驗收的依據。
2。3.3 施工過程質量控制
主要從人、機、料、法、環五個要素進行控制， 通過完善的質量管理體系對消防工程產品質量進行測量、分析、改進。
1）參與消防工程施工的人員。工程項目參與各方員工素質是工程質量的基本保證。消防工程專業施工企業的施工人員必須掌握國家有關施工驗收規范和質量標準， 主要技術負責人不僅要具備相應技術職稱，還應對消防設計、消防設備及整個工程防災系統掌握了解，具備整合協調能力。應選擇具有消防工程施工經驗的施工人員， 對其進行崗前培訓， 主要包括消防工程施工技術培訓以及安全生產知識培訓。并且在各分項工程開始前應對施工班組進行技術交底， 使其領會設計意圖、設計變更的要求， 執行和滿足施工規范、規程、工藝標準、質量評定標準和建設單位的合理要求。
2）施工機械和檢測儀器。包括施工機械、測量儀器、檢測儀器等。常用施工機械應定期進行維護保養， 使其保持完好狀態。配備經檢驗合格的儀器， 對所敷設線纜的絕緣電阻、火災探測器的性能等進行測試。
3）工程材料、設備。消防工程使用的所有材料與設備必須符合設計要求并應從具備良好的信用和質量管理體系的廠家中選取， 并應具備材料證明書或合格證， 消防專用產品應為公安部消防產品信息網上網產品， 并嚴格按物資進場驗收程序進行驗收， 嚴防不合格物資進入施工現場。
4）施工質量管理制度和施工組織設計。（1） 施工質量管理制度。建立完善的施工質量檢驗制度， 隱蔽工程檢查驗收制度， 施工技術復核制度， 質量責任制， 并在實施中得到有效落實， 實物質量符合設計、合同和強制標準要求。工程施工中發生了質量問題（事故）要按程序及時進行處理，不留隱患，且質量責任明確，項目質量技術管理人員均應持證上崗。現場質量管理應處于受控狀態。（2） 施工組織設計。應根據工程特點編制有針對性、可操作性強的施工組織設計， 工程的重要部位及專項應有施工方案， 施工方案中應明確有關的施工工藝與技術要求、工程成品、半成品的防護措施， 工程項目按照施工組織設計方案的要求組織實施。（3） 文件和資料管理。應做好消防工程項目有關文件和過程施工記錄的管理工作， 確保施工中所使用的圖紙與規范的有效性，并收集保管好消防工程從建審開始形成的有關文件和記錄， 如建設工程消防設計審核意見書或消防設計備案資料、圖紙自（會）審記錄、施工組織設計（方案）、主要材料或設備質量合格證明文件、隱蔽工程檢查記錄、水壓試驗記錄、絕緣電阻測試記錄、施工技術復核記錄，技術質量問題（事故） 論證處理記錄， 建筑材料、構配件、設備進場檢查驗收記錄， 報告， 分部、分項工程質量驗收資料等。
5）施工內外環境。在施工組織設計中編制可操作性強的確保安全生產和文明施工的技術保證措施并嚴加落實， 與土建總承包單位、其他專業承包單位共同締造一個整潔有序、安全有序的施工現場。
2。3.4 驗收階段的質量控制
為確保消防工程一次性通過消防部門的驗收， 消防工程報驗前， 應做好驗收前的各項準備工作，主要如下：
（1） 落實土建專業與消防相關的作業是否已竣工，如防煙樓梯間或封閉樓梯間、管道井分隔、防火卷簾門等的施工是否已經完畢；
（2） 做好消防系統各子系統的調試與整體聯動調試工作， 檢查水泵接合器、室外消火栓的有關閥門是否安裝正確， 均已開啟。
（3） 各消防設備的電源是否已到位。
（4） 各消防聯動設備的聯動關系是否已按設計及規范要求設置， 并經自檢正常。
（5） 有關的標志是否已完備， 如水泵接合器、水泵屬何系統的標志。
（6） 工程竣工圖、竣工資料是否已完備。
3調試階段的項目質量管理
3.1油罐的試漏試壓
在油罐試漏試壓時應注意以下幾點：1）嚴格按照有關施工驗收規范進行各種試驗。2）充水試驗時，注意正確選擇水質、水溫和進水速度。3）在固定頂油罐強度及嚴密性試驗中，罐內水位在最高設計淤下1。0米時，應進行緩慢充水升壓。4）固定項油罐的穩定性試驗時，應充水到設計最高液位用放水方法進行。試驗時應緩慢降壓，防止引發油罐吸癟事故，達到試驗負壓時停止，觀察有無變形。
3.2輸油管路試壓試漏和吹掃
輸油管在試壓試漏和吹掃時，極易引發事故，爆裂等。因此，應劃定，清理閑雜無關人員。試驗中若發現泄漏，不得帶壓處理。試驗宜采用空氣為介質，應在試驗合格后進行，其試驗壓力為設計壓力。
篇3
傳統的開發是瀑布型，從設計到構建、測試、，就像瀑布從上到下的過程，而這過程通常需要半年或一年，甚至更長時間，構建的東西等到對于市場也已經沒有意義了。因此，敏捷營運而生。
敏捷一詞對于我們來講已經不再陌生，在業界已經成為一種軟件開發活動的推薦模式。但是，到底具備什么特質的軟件開發活動可以稱之為“敏捷”？
Rally Software亞洲區副總裁陳彩倫將敏捷精煉為“企業能感應市場變更，并能自信迅速做出反應的能力?！彼J為目前各行各業都發展迅速，伴隨著互聯網帶來的沖擊，云計算、大數據的需求增多，企業就需要更快的迭代開發、測試，需要更快的響應、修復。企業隨時面臨被淘汰出局，只有真正敏捷的企業才能對市場的各種變化做出迅速反應。
敏捷開發可以使軟件項目的構建被切分成多個子項目，同時進行并經過測試，具備集成和可運行的特征。這樣的做法大大縮短了開發周期，促進了團隊間溝通，可以使團隊的開發效率大大提升。
敏捷的核心在于“快”，通過硬件和軟件開發融合發力，實現軟件開發過程“快”，以快來取得“準”，以“準”來破“變”，實現軟件產品價值成功交付。
Rally是一家提供企業級敏捷開發管理平臺和敏捷轉型咨詢服務的公司，去年正式進入中國。在中國目前擁有銷售、售前和實施顧問、咨詢顧問和技術顧問。Rally的解決方案不僅包括培訓指導和咨詢，提供敏捷轉型方案，同時也提供Rally ALM 平臺，幫助客戶進行敏捷管理。Rally提供一個端到端的，從客戶訴求、項目管理、需求管理，到質量管理，貫穿整個過程的管理平臺。
“雖然是一個端到端的平臺，可是我們不排除跟第三方工具的結合。我們提供的是一個開放的平臺，有120多個接口，可以融合多家公司的平臺和工具，我們的目的不是取代，而是融合與共存。” Rally亞洲區技術客戶經理鐘順發表示，“目前Rally在中國的用戶包括思科、BMC、EMC、福特、愛立信、華為等?！?/p>
篇4
關鍵詞 敏捷開發；敏捷項目交付模型；敏捷測試
中圖分類號TP31 文獻標識碼A 文章編號 1674-6708（2013）83-0197-02
從上世紀50年代軟件出現開始至今，軟件開發方法先后經歷了無規則的編碼和測試、結構化方法、面向對象的方法、能力成熟度模型CMM和輕量級開發方法等各個階段?？v觀軟件開發的發展史，軟件開發方法的演變是有規律可循的，遵循著一條從“計劃和預測”到“反饋和適應”的歷程。造成這一演變過程的原因如下：
1）軟件使用者的主體從大型尖端領域逐漸向廣泛的企業應用領域轉變；
2）人們對軟件系統需求的認識提高；
3）市場經濟的發展，以及市場需求的頻繁變化；
4）面向對象技術的應用和普及。
而今，企業面對的是快速變化的市場，在這樣的市場環境下，收集用戶完整的、穩定不變的系統需求是不可能的。面對無法預知和不斷變化的需求，傳統的軟件開發流程明顯已無法適應，而敏捷過程將程序代碼和系統需求緊密的聯系在一起，將系統需求視作流動和變化的需求的思想，則正符合現今軟件開發的現狀。
1 敏捷開發的興起
敏捷方法誕生于2001年，由J.Highsmith和R.C.Martin發起，由一批業界專家參與成立了敏捷聯盟，并概括出了一系列讓軟件開發團隊具有快速工作、相應變化能力的價值觀和原則。
在敏捷聯盟的官方網站上，可看到敏捷宣言的完整內容：
1）個人與溝通勝過過程與工具；
2）可工作的軟件勝過面面俱到的文檔；
3）客戶協作勝過合同談判；
4）相應變化勝過遵循計劃。
具體來說，傳統的順序開發模型（瀑布模型、V模型、W模型）的一個重要的特點就是所有的活動都是有順序的。順序開發模型成功使用的一個前提是軟件系統具備完善和明確的需求。如果在項目開始階段無法進行完善的需求分析和設計，則順序開發模型就很難被成功的使用。為了解決順序模型的不足，出現了增量迭代模型。從本質上說，敏捷開發就是一種迭代的增量的開發模型。這種模型的優點如下：能很好的適應需求的變化；早期的迭代可以降低風險；集成是持續的而不是在項目后期進行的“大動作”；在每次迭代中發現和更正缺陷并能不斷反饋并改進開發過程[1]。
如果要用一句話來描述敏捷開發，那么敏捷開發應該是：以人為本、輕載、基于時間、just Enough、并行并基于構件的迭代和增量的軟件開發過程。
2 敏捷開發的原則
敏捷聯盟成立后，又陸續形成了敏捷的十二項原則（本文不在詳細展開，詳細描述見敏捷聯盟官方網站），其主旨思想大體如下：敏捷開發中需求是逐漸展開的，在項目初期不提倡過渡的需求分析，對需求變化的響應是動態的；敏捷項目應該分成從幾周到幾個月間隔的迭代周期，每一個迭代周期盡量產出潛在可交付的軟件產品，用戶的反饋作為下次迭代的基礎；可工作的軟件是衡量項目進展的主要依據；敏捷開發整個過程是持續的，帶有反饋的和自我完善的輕量級的過程。
基于敏捷指導思想，形成了不少敏捷軟件開發方法(例如XP、scrum等)，它們大都強調適應性而非預測性、強調以人為中心，而不以流程為中心，以及對變化的適應和對人性的關注。以XP（extreme programming）方法為例，它消除了大多數重量型過程的不必要產物，建立了一個漸進型開發過程。該方法將開發階段的4個活動（分析、設計、編碼和測試）混合在一起，在全過程中采用迭代增量開發、反饋修正和反復測試。并且它作為一種面向客戶的開發模型，開發過程中對需求改變的適應能力較高，即使在開發的后期，也可較高程度地適應用戶的改變。XP開發模型與傳統模型最大的不同是其核心思想是交流（Communication）、簡單（Simplicity）、反饋（Feedback）和進?。ˋggressiveness）[2]。這種開發模型的主要優點如下：
1）采用簡單計劃策略，不需要長期計劃和復雜模型，開發周期短；
2）在全過程采用迭代增量開發、反饋修正和反復測試的方法，軟件質量有保證；
3）能夠適應用戶經常變化的需求，提供用戶滿意的高質量軟件。
縱觀所有敏捷開發方法，其基本都具備輕載、基于時間、Just Enough、并行并基于構件的迭代和增量的特點，而且具有類似的敏捷項目交付模型。
3 敏捷項目交付模型
敏捷項目交付模型是一種敏捷軟件項目管理的生命周期模型，它是基于敏捷開發迭代和增量特點的過程模型[3]。該模型把敏捷軟件項目的生命周期大體可分成項目規劃、項目啟動、迭代開發與三個階段。各個階段分別介紹如下：
1）項目規劃階段
敏捷開發中的項目規劃階段類似于傳統開發過程中的項目可行性分析和早期的需求收集階段，該階段的主要工作如下：
（1）就要開發系統的戰略目標、業務愿景和初始項目需求等與關鍵涉眾達成共識；
（2）根據收集到的資料，設計與決策系統開發的關鍵技術架構問題；
（3）評估項目的工作量與成本，輔助客戶決策項目的可行性；
（4）進行項目的初始計劃制定。
2）項目啟動階段
該階段是一過度階段，處于項目規劃后正式開發前，主要工作是為項目開啟準備各種所需資源，包括開發場地布置、軟硬件環境的準備和項目團隊的組建等。另外，通常為了使此后的迭代開發階段能夠順利進行，還有為第一次迭代進行詳細的需求分析工作。
3）迭代開發與階段
該階段是敏捷項目交付模型的核心部分，基本上所有的開發工作都在該階段展開與實現。在迭代開發與階段，項目組會根據目標系統的正式版本將該階段分解成多個重復的過程，并且每次過程基本上都是一次目標系統的增量在開發環境中實現，并從開發環境到生產環境的遷移。每次迭代開發與又可細分為迭代開發、用戶驗收測試（UAT）和三個小階段。各階段的介紹如下：
（1）迭代開發是一個有固定時間周期的、在開發和測試環境上完成系統增量的過程，增量流程大體由需求分析活動、設計實現活動、集成測試活動、客戶測試活動組成。每次迭代都會產生潛在可交付的產品；
（2）多次迭代開發對應一次，多次迭代后每次前，會根據項目需要進行用戶驗收測試。目標是讓客戶代表從系統最終運營的角度測試系統行為，另外，該階段也可作為項目團隊完成目標的緩沖區；
（3）過程在敏捷開發中有里程碑的作用，其業務意義大于技術意義。使用敏捷軟件交付模型，第一次會在較早的時間發生，這對于提升客戶投資收益，根據市場反饋調整項目走向都有幫助。
4 敏捷開發中的測試
對于敏捷的理解，一般認為最為關鍵的是需要注意兩個方面，即“高速迭代”和“持續不斷的客戶反饋”[4]。而要達到這樣的要求，傳統的注重流程的規范，文檔的齊備，走完整的bug處理流程的測試過程，明顯已不符合敏捷的初衷。
那么敏捷開發中測試有何特點？，簡要來說，如下所述：
首先，就測試的階段來說，敏捷開發中的測試貫穿于整個軟件開發生命周期中（傳統軟件開發模型中，測試只是作為編碼后的一個獨立階段出現）。其次，敏捷開發是迭代和增量的過程，這就意味著測試人員在每個代碼增量完成時，都要測試它，測試工作也是迭代的展開，并且時間更緊，壓力更大。開發和測試是并行進行的，程序員從來不超前于測試人員（在傳統軟件開發模型中，編碼和測試過程是串行的，先編碼后測試）。再次，敏捷開發中，測試人員需要緊密的與客戶合作來定義每一個需求的接收標準；而且測試過程還可以向項目組隨時反饋開發中遇到的問題。而不像傳統測試中，測試由詳細的需求驅動，并且發生在編碼之后。最后，敏捷測試中，提倡持續集成和構建，集成的頻率較高，并且可為開發提供持續的反饋。
5 結論
其實，不管正在使用的是哪種開發模式，都會經歷幾乎同樣的軟件開發生命周期元素。敏捷的不同之處在于時間段明顯變短，而且活動同步進行。因此，參與者、測試和工具都需要適應這一變化。同時，也應該看到沒有哪種開發模式可以放之四海而皆準，只有不斷的被實踐和驗證才能持續完善[5]。目前，敏捷還在不斷發展，更多的項目在實踐敏捷，應用的普及和成功的案例正在不斷擴大。
參考文獻
[1]鄭文強，馬均飛.軟件測試管理[M].電子工業出版社，2010.
[2]張友生，李雄.常用軟件開發模型比較分析.中國系統分析員，2005(1).
[3]桑大勇，王英，吳麗華.敏捷軟件開發方法與實踐[M].西安：西安電子科技大學出版社，2010，5.
篇5
1.1敏捷方法介紹
敏捷方法誕生于2001年初，當時，由于看到開發團隊陷入越來越沉重的軟件過程當中。業界專家們總結出了一套使團隊具有快速工作、響應變化能力的價值觀和原則。基于這一套價值觀和原則的軟件開發方法，被稱為敏捷軟件開發方法（AgileSoftwareDevelop-ment），而這類方法也發展出相應的敏捷項目管理體系（AgileProjectManagement）。敏捷開發方法及項目管理體系統稱為敏捷方法（Agile）。
1.2敏捷方法的優點
敏捷方法是一種以人為核心、迭代、循序漸進的開發及項目管理方法。該方法使用了迭代、增量等方法來優化可預見性并控制風險。它靈活、高效、可持續，可以幫助軟件開發團隊有效地應對復雜的適應性問題。
該方法受到擁護和流行是因為采用了該方法后，團隊得到的收益：據統計，敏捷方法可以讓團隊的效率提升3～10倍；軟件的質量也更有保障；團隊成員有良好的發展機會；技術能力和團隊協作也得到了提高。
2敏捷項目的快速啟動
2.1什么是快速啟動？
敏捷軟件開發項目通常會通過1～4周的快速啟動（QuickStart）工作，制定出迭代開發計劃，然后在開發過程中逐漸完善需求。QuickStart是一種高效的項目啟動方式，主要用以在項目開始之前識別關鍵的驅動因素，這種方式能夠讓關鍵干系人認可并理解即將交付的產品。如圖1所示。
3QuickStart的前期準備
3.1邀請相關參與人員
QuickStart過程中需要邀請參與的人員包括：核心團隊、領域專家及用戶代表、關鍵干系人（受益人、高層領導等）。核心團隊一般包括產品負責人、需求分析人員、項目負責人及核心團隊成員。這些人需要全程參與整個QuickStart，他們是成果的主要貢獻者。領域專家及用戶代表主要在用戶建模、場景建模等環節為團隊提供專業的意見和建議。他們可以在某些階段時參與到QuickStart中來。關鍵干系人主要參與QuickStart的啟動和展示匯報的環節，并對產出成果進行確認，特別是需要對產品目標和計劃進行確認和授權。
3.2擬定QuickStart的計劃
在QuickStart正式開始之前，項目負責人和產品負責人需要擬定QuickStart的整體計劃。以一個2周的QuickStart為例，整個QuickStart計劃可以這樣安排：
QuickStart啟動及業務目標識別（0.5～1天）
參與人員包括：核心團隊、領域專家及用戶代表、項目領導
產出物：產品目標
識別主要角色及場景（3～5天）
參與人員包括：核心團隊、領域專家及用戶代表、項目領導
產出物：主要用戶角色列表、核心場景及流程、頁面設計及原型
需求列表梳理（1～2天）
參與人員包括：核心團隊、領域專家及用戶代表
產出物：用戶故事清單
規模及成本估算（0.5～1天）
參與人員包括：核心團隊
產出物：估算結果
迭代/計劃制定（0.5～1天）
參與人員包括：核心團隊
產出物：迭代/計劃
QuickStart的成果匯報（0.5天）
參與人員包括：全體團隊成員
產出物：成果匯報材料
4引入的各種流程建模及分析技術
4.1識別業務目標及愿景
業務目標的識別和確定需要符合SMART原則；需要了解問題的背景及上下文信息；需要定義驗證問題成功的標準；需要界定問題的范圍，例如規模指的是數量還是金額，或者單品規模；需要明確并逐步完善關鍵干系人信息；需要明確關鍵資源，例如領域專家或者關鍵信息等等；還需要明確該問題的各種約束條件。
4.2識別角色及主要場景
用戶識別從頭腦風暴的形式開始，盡可能識別出更多的用戶，然后挑選出主要的用戶和角色，并且為用戶進行用戶畫像，并建立用戶模型。通過理解用戶的目標需求和痛點，梳理出更多的細分用戶場景，之后對用戶場景進行優先級排序、分析，以發現其中的問題或隱含的機會。
對問題和機會進行結構化的分析可以通過這幾個方面來進行：
（1）進行問題/機會的原始描述；
（2）通過事例來說明問題/機會的現象；
（3）對問題/機會進行定量的分析；
（4）對問題/機會進行定義并明確對于問題解決的期望；
（5）將問題和機會的相關分析及描述標識在用戶場景描述的周圍。
業務流程梳理的過程中可以將之前識別出來的用戶場景在進行串聯。較高層級的業務流程將各個場景串聯起來之后，就可以在場景中進行場景流程的細化和展開，分析出流程步驟和各個步驟的細節。業務流程場景中的步驟細節需要包含這些信息：場景名稱、場景入口的背景說明，本場景中需要跟進解決的問題，場景中事件步驟，某個步驟的細節說明，還需要有場景的出口目標。
4.3產出Productbacklog
根據上一環節中梳理出來的用戶模型、場景模型、業務流程以及場景細節，開始進行用戶故事的梳理，并建立用戶故事列表。用戶故事是為了方便與用戶溝通而記錄的信息，它不是需求文檔，它需要以用戶能理解的方式來進行描述。它的目的是要將用戶的關注點從“寫”轉移到“交流”上，讓開發團隊做用戶真正需要的東西，而不是用戶寫的東西。
一個用戶故事的描述樣例是：“作為一個<角色>，我想要<活動>，以便于<商業價值>”。一個用戶故事是否成功可以從以下幾點（INVEST）來判斷：是不是獨立的（Independent），是不是可協商的（Negotiable），是不是有價值的（Valuable），是不是可以估算的（Estimable），是不是大小合適、粒度相似的（Sizedappropriately），是不是測試能夠測試、業務能夠驗收的（Testable）。
4.4梳理依賴、估算及優先級排序
核心開發人員對已經梳理出來的用戶故事進行初步的技術解決方案分析，確定用戶故事的技術實現可行性和一些可能的實現方案。然后從邏輯層面和技術實現層面，對用戶故事列表中的故事進行一次檢視，對于一些無法避免的用戶故事之間的相互依賴，需要在故事卡片上標識出來。對已經梳理出來的用戶故事進行估算，估算內容包括故事規模估算、工作量估算等。
估算完成后可以根據用戶故事的價值、重要程度、依賴等信息進行用戶故事優先級排序。排序的原則是優先考慮那些最有價值的故事、最關鍵的故事、被其他關鍵故事依賴最多的故事。
4.5制定交付計劃
經過以上各個環節，團隊已經得到了了一份標識了優先級、依賴關系、工作量估算等信息的用戶故事列表，此時可以開始來制定交付/計劃了。根據已經排序的優先級選擇并整理每個迭代/版本需要完成的用戶故事，使用每個故事上之前已經完成的規?；蚬ぷ髁抗浪?，加上功能聯調和集成可能增加投入量的buffer值，整理并安排出整個交付計劃。
對于最近的一個交付周期的安排是團隊應該投入最多時間進去分析和做進一步估算的。確保第一個交付周期的所有用戶故事清晰且被團隊理解，并且該周期中的所有用戶故事都已經有較明確的技術實現方案，可以在QuickStart結束之后馬上進入開發實現。如圖2所示。
4.6匯報QuickStart的成果
QuickStart的最后一個環節是召開QuickStart成果匯報的會議，該會議的邀請人員包括項目團隊全體成員、項目領導、相關干系人。會議上向項目相關人員匯報QuickStart的成果產出，包括確定項目產品目標及愿景、需求列表及交付計劃。在展示項目團隊QuickStart成果的同時也獲取相關領導及干系人對成果的認可和支持，統一項目團隊人員的認識，為匯報結束后立刻投入到需求的開發實現奠定基石。
5結束語
篇6
【關鍵詞】代建模式；工程建設監理；管理水平
近年來隨著我國國民經濟的高速增長，基礎設施和城市公用事業建設的發展迅速，但在政府投資的絕大多數項目中，我國一般仍舊采用的是建設單位自建自管的傳統管理模式，這種模式普遍存在這樣的問題:職責不清、政府管理與投資主體、建設單位和使用單位沒有協調一致。國家希望通過建立代建制系統，解決投資項目的馬拉松式工期問題。但是如何在代建制下更好地發揮監理作用的探討也是十分必要的。
一、代建制實施過程中存在的問題
由于代建行業門檻低，代建單位的項目管理水平及從業人員素質有待提高，代建范圍尚需進一步拓寬。首先，從代建公司內部看，一是大部分代建公司人員配備不足；二是即使是配足了人員，其組織結構也不盡合理，人員的素質和能力不能滿足要求，項目管理人員的專業水平都很高，現場實踐經驗較多，但是從業人員明顯知識和能力不足，缺少復合型人才。其次政府指定專業代建公司模式下的代建制企業中，綜合型的能承擔各種行業的綜合代建工程管理的公司比較少，服務范圍比較狹窄，在一定程度上制約了代建制在我國的發展。
業主的觀念沒有完全轉變，“建設”和“運營”沒有真正分離。實行代建制的目標之一就是要解決“建設、監管、使用”多位一體的矛盾，但在代建制的實施過程當中，有些使用單位為了部門的利益，對于代建工作存在一定的抵觸情緒，不是自覺自愿接受項目代建，而是在代建過程中或是不積極主動配合，不履行應承擔的責任；或是不愿放棄自己的權力，利用甲方身份超越權限干涉代建單位的正常工作。這樣做不僅影響了代建單位對項目的管理，也影響了代建單位的積極性和主動性，進而影響到項目的順利實施。
因此，代建制下的監理的作用不應弱化，反而應該在適應新情況的前提下，與時俱進，適當加強。
二、代建制下各方應明確的職責
首先必須讓使用單位真正了解代建制在項目管理中的巨大作用，改變他們落后的思想觀念，以此來推動代建制的健康發展。同時，還應明確對代建工作實施監管的具體主管部門，對代建項目的招投標、合同簽訂及執行進行必要的監理；對于代建單位應該不斷提高代建單位項目管理水平，進一步拓寬服務范圍。擴大代建企業規模，增加人員配備，并保持其組織機構的合理性；監理單位應該切實發揮好監察，管理作用，建立從業人員培訓機構，制定相應的人員聘用、考核激勵、培訓計劃，加大監理人員素質培養的力度，在增強企業核心競爭力的同時，拓寬為代建工程服務的范圍，贏得更多市場。但是監理并不能在現場進度，資料和驗收以及造價控制完全按照使用單位的意愿進行，所產生的矛盾亟待解決，監理單位要充分發揮監理作用以保證代建制度能夠健康，穩定的發展。施工單位應該準確的按照使用單位的要求切實保質保量的完成任務，以促進企業能夠健康發展。參建各方切實保證自己的職責，才能保證代建項目的順利實施。
三、代建制下發揮監理作用的對策
代建制下的工程監理新的體制的實質,就是樹立監理工程師在工程施工管理過程中的核心地位,作為建設單位,代建單位以外獨立的第三方,監理工程師運用建設單位及代建單位委托的權力,對工程質量、工程進度、工程費用實行全面監理。
1.完善代建制下監理單位的組織方式，建立公正、科學的監理單位選擇機制。首先，要打破行業壟斷，掃除一切人為設置的監理進入壁壘。其次，要盡快建立和完善全面市場化的代建制下監理單位選擇機制，具備條件的項目應采用公開招標機制來選擇監理單位，讓真正合格的監理單位主體來監理政府投資項目。
2.監理單位要積極加強和使用單位、代建、施工單位四方的溝通，發揮“油”的作用，監理單位及時準確的把施工情況反映給代建單位，代建單位按照使用單位的要求把信息轉述給施工單位和監理單位，并督促監理加強對施工的管理，避免各參建方之間扯皮、糾紛、責任推卸等情況。
3. 加快培育專業化監理隊伍。代建制下監理企業要求從業人員有較高的綜合素質,不僅要具備較高的專業技術水平,而且還要通曉法律、經濟、財務、施工、預算、管理等相關知識,有較強的語言表達能力、敏捷的思維反應能力和綜合協調能力等。監理是代建管理體制改革的重要內容,充分發揮監理的作用是強化質量管理,控制工程造價、提高投資效益及施工管理水平的有效方法。實踐證明,一項代建工程實行了有效的監理,不但減少了不合理的支出,保證了工程質量和工期,還避免了許多合同糾紛,并能確保國家建設計劃和工程合同順利實施。
四、結語
代建制在我國還處于起步階段，在推行過程中難免會存在許多問題和困難。代建單位的角色是代行業主職能，是國家推行的方式，只是政府工程建設方式的可選項，而監理是國家制度，是強制性的。項目是否需要監理，與是否實行代建沒有關系，而與該項目的性質有關，若是符合“建設工程監理范圍和規模標準規定”的項目，必須監理。但只要轉變觀念，提高認識，進一步完善制度，健全市場，積極努力尋求解決問題的方法，充分發揮監理的作用，就一定能使代建制朝著健康的方向發展。
參考資料
[1]宮孟飛;馮婧;王永軍;;國際工程項目管理模式的比較及發展趨勢預測[J];建筑設計管理;2008年05期
[2]馬世驍;牟瑞;高春山;;工程項目管理中的并行工程理念分析與應用[J];沈陽建筑大學學報(社會科學版);2007年03期
[3]湯峰;石遠路;;淺議國際工程項目管理模式[J];企業技術開發;2007年07期
[4]譚恒;;工程項目管理新型模式探索研究[J];科協論壇(下半月);2009年07期
篇7
和信息服務業
杰出貢獻企業獎
十多年的信息技術服務歷程中，明基逐鹿服務了大量的各行業的領導企業，在機械制造、汽車制造、快速消費品、零售連鎖、酒店服務、金融服務、高新技術、房地產、公用事業、傳媒及網絡等數十個行業及領域能夠提供針對性的解決方案和知識分享體系。
明基逐鹿成立于1998年，前身為明基全球信息技術服務與研發中心，在全球100個以上國家和地區有營運據點，提供IT服務的軟件系統開發和支持團隊。明基逐鹿擁有近20年軟件系統研發營運經驗，將明基集團20年以上全球營運管理經驗與數百家知名企業客戶累積的導入經驗，透過HCM、BPM、SRM、MES規劃導入及IT Service、ITO業務分享給追求卓越的企業客戶，提供橫跨兩岸領先的企業信息化管理整體解決方案。
以BenQ國際品牌營運經驗為基礎，提供企業信息化整體解決方案：明基逐鹿是明基友達集團旗下公司。明基友達集團由十余家獨立公司組成，橫跨信息科技、消費電子與醫療電子等領域。各集團公司分別深入產業布局，不僅是各行業內的創新領導者，同時也形成了高度整合的價值鏈。
跨越的業務布局：明基逐鹿的業務區域覆蓋中國華東、華南、華北及臺灣地區，公司總部位于蘇州。布局于北京、上海、廣州、南京、杭州、深圳、臺北等各大城市的分支機構， 持續為企業提供包括IT管理咨詢服務、管理軟件在內的一站式服務，力爭以最快的速度為客戶提供及時優秀的全方位管理及信息化服務。
專業的顧問團隊，擁有國際化管理理念與實戰經驗：明基逐鹿是由明基集團企業e化服務團隊和具有多年HCM、BPM、SCM、MES等經驗的專家所組成，在十幾年的信息系統建設過程中，成功地完成了明基集團全球營運的信息系統規劃、建置及維護，累積了眾多跨國、跨領域的信息化項目實施成功經驗。公司成立至今，技術、服務隊伍不斷發展壯大，現已有四百多位各領域的專業咨詢顧問及軟件研發工程師。
專業源自實踐，最值得信賴的信息服務專家：十多年的信息技術服務歷程中，明基逐鹿服務了大量的各行業的領導企業，在機械制造、汽車制造、快速消費品、零售連鎖、酒店服務、金融服務、高新技術、房地產、公用事業、傳媒及網絡等數十個行業及領域能夠提供針對性的解決方案和知識分享體系。
篇8
產品介紹
AgilePoint BPMS產品項中包含AgilePoint Envision（流程規劃與設計工具）、AgilePoint Developer（開發圖像式IT服務組件的環境）、AgilePoint Server（流程部署與運行服務器）、AgilePoint Enterprise Manager（整體流程管理接口）四個組件。
圖像式組件是AgilePoint企業流程整合平臺中最基本的組成要素，它是由Visual Studio環境開發而成的API，經由封裝技巧以圖形組件的方式使用于AgilePoint Envision中。
因為將IT資產與應用通過抽象的方式萃取出來，所以企業流程規劃者、商業決策人士可以在信息技術工作者的協助下，以直觀的組裝取代向信息技術工作者開立系統或流程需求，組成具有可視性的流程模型，再根據業務環境的變化彈性調整，順應外在變化。
全球IT權威研究機構高德納（Gartner）2007年評選Ascentn AgilePoint為BPM領域最酷伙伴，其最新一期的研究報告中更指出，AgilePoint BPMS是.NET平臺上惟一具備EPMs架構的流程管理平臺，最主要的原因是AgilePoint企業流程整合平臺不論是在流程設計、開發、部署、運行上都采用單一的模型，Model-Driven（以模型來驅動流程）的概念貫穿流程平臺中所有的組件，且可彈性調整，快速響應動態的商業需求。
通過在AgilePoint Envision中組裝流程的過程，商務決策人士與IT工作者將可協同合作，規劃出適合業務需求的商業流程模型，并且不需要經過轉譯程序代碼的作業即可將流程實際部署至AgilePoint Server。正因為這種不同以往的操作方法，后續運作流程時如果產生需求變化的狀況，也僅需要改動流程模型配置即可完成調整，模型驅動讓流程模型有了明確的可視性與一致性。
AgilePoint流程模型帶有可解析的XML標記，藉由開放式的標記語言，可將分散且各自為政的應用系統與信息來源互相連接，讓異質系統以松散耦合的連結方式執行溝通，不僅可整合日常商務所需提供服務，也可大幅降低IT維護成本。
在模型驅動的基礎上，流程設計、開發、部署、運行都采用單一的模型，因此開發完成后的流程模型，透過XML直譯的方式，不僅可直接、運行，更能夠透過AgilePoint Enterprise Manager中的可視化接口直接監督流程的運行狀況，充分掌握流程進度。
AgilePoint BPMS除了整合Visio中所有的功能特性，讓有相關使用經驗的使用者可以立即上手外，企業過去以Visio繪制的流程圖也可以匯入到AgilePoint中，透過重復使用形成BPM應用，充分為企業整合了既有的Visio資產與員工使用技能，不但節省流程開發的時間與成本，更加速使用者對工具的接受度，簡化且降低導入風險。
AgilePoint BPMS平臺強大的整合特性還具有支持多前端表單格式、整合SharePoint、整合Visual Studio、整合Biztalk Server等優勢。此外，通過Web Service與AgilePart開發，將可藉由簡單的點擊與拖曳和其他IT資產產生連接性和互操作性，整合點對點流程。目前AgilePoint大中華區團隊已經有整合SAP、Oracle ERP、JD Edwards、Lotus Notes、Siebel、PLM等豐富的實施經驗。
產品特色
彈性組裝，隨需應變 與一般可預先定義的業務系統不同，流程整合平臺所串接的是對企業有高度影響性的點對點作業，這些介于各系統間的流程，常會有許多無法事先定義的行為，因此不能遵循傳統的代碼編寫作業促使流程自動化。AgilePoint流程整合平臺可根據不同的業務需求，彈性、動態地組裝流程。
可視性將有效促成協同合作對于企業而言，所有的商業邏輯幾乎都集中在商務決策人士的經驗中，但他們不見得非常了解企業的IT資產及其操作，信息工作者如能將相關應用抽象出來，以商業決策人士能夠理解的方式萃取包裝，則商業決策人士即可透過鼠標拖曳的方式快速組裝流程模型、生成應用。
流程采用一致化模型除了圖形化的流程與邏輯組裝接口外，確保流程在建置、開發、部署、執行均具有可視性的一致化模型，才能確保業務需求從建置流程模型與開發部署的過程中不會因為編寫代碼等工程開發周期而喪失了當初彈性組裝的精神，這在建立企業流程整合平臺時，是非常值得考慮的重點。
滿足動態 (dynamic)需求企業對流程的動態需求主要體現在兩方面，分別為節點動態與流程動態兩者。節點動態是指在單一組件中，藉由屬性設定可在實際運作時讓流程達到動態判斷的能力。流程動態則是指流程實際后，仍可根據業務表現動態調整，讓流程具備回退（return）/取回（rollback）、跳躍、停止、遷移至新流程、重新啟動的能力，AgilePoint在節點動態與流程動態的雙重實現能力十分出色。
提供管理性 過去許多的業務流程，例如新產品開發過程、動態審批等步驟，都仰賴電子郵件、會議、電話等方式，簡單地進行協同合作，但管理機制始終無法確切落實，因為當中隱含了許多不確定性，如郵件遺漏或者是人為疏失等，所以管理者常有無法明確掌握流程進度的疑慮，透過AgilePoint流程管理平臺，所有信息將根據邏輯及流程規劃自動地傳遞與運行，可大幅提升信息的可視性與管理性。
建立介于人與人、人與系統、系統與系統間的整合 AgilePoint做為企業流程整合平臺，將可串連起介于人和系統之間的各式溝通，整合介于員工、顧客、供貨商之間的流程（people-to-people），讓企業員工可以以企業入口或其它網頁應用形式連結內部信息資產（people-to-system），并且讓異質系統間突破語言限制，執行順暢的數據交換（system-to-system）。
用戶應用體會
Ascentn所開發的新一代模型驅動BPMS在2005年時才正式對市場發表，但領導開發團隊過去20多年來厚植于J2EE BPMS領域的顧問經驗及海外實績，讓進入中國市場不久的AgilePoint隨即獲得許多客戶的肯定。
國土資源部將AgilePoint應用于全國資源項目大調查中，整合舊有系統，實現項目管理與流程監控需求，因其流程中需結合許多次級單位，實現動態分派任務與流程之需求，AgilePoint的節點動態性與流程動態性可充分吻合需求，因而采用AgilePoint BPMS做為流程整合平臺，采用后歷史資源共4047個項目及時入庫，后續應用于調查共計7000多個項目，使用單位共計523個。
廣州市政府服務中心共有210多個服務窗口，776項政府服務，透過AgilePoint有效整合多個異質系統，服務中心工作人員將可透過單一窗體直接連結查詢多個數據庫，以事件驅動導向（Event-Driven）有效地提升公務流程處理效率，充分實現面向服務之精神。
遠東金士頓科技（Kingston）作為全球內存條制造大廠，工廠與配銷橫跨世界各地，因此有效整合制程、業務支持系統、人事管理系統、客戶關系管理系統等，成為遠東金士頓科技實現面向服務架構的第一要務，目前該公司已在中國優先導入AgilePoint流程管理平臺，期能有效統合多異質系統，創造流暢的業務流程。
篇9
隨著互聯網的觸角深入到生產生活中的各個層面，軟件已經不像以前那樣只是支持辦公和家庭娛樂這兩大主題了，而是成為現代商業的靈魂。軟件安全問題主要圍繞著軟件漏洞和易被攻擊脆弱點，它們都來自于軟件的設計和實現。Internet催生了電子商務，移動互聯網使得APP變得如火如荼，未來物聯網也許可以將生活中的一切元素都納入到通信網絡中去。因此軟件安全問題將成為計算機安全的核心，而非防火墻等網絡硬件，或是諸如加密等手段。軟件安全是一切計算機安全性問題的根源，如果軟件行為出現異常，與之相關的可靠性、可用性等方面問題就會隨之暴露。軟件安全問題并不是互聯網出現后才有的，只不過互聯網是目前最容易攻擊軟件的途徑罷了。
2軟件安全的現狀
2.1人們的認知
隨著黑客攻擊的新聞時常見諸媒體，人們對計算機安全問題有了一定認識。但不幸很多計算機安全人員和計算機教育培訓人員都忽視了軟件安全的問題。一味地推崇某種軟件平臺是安全的，單純大力增加對網絡安全硬件和軟件的投入，這些做法是盲目甚至荒謬的。一切安全性都不是靜態特性，也沒有任何軟件是絕對安全的。軟件安全問題的關鍵節點是軟件的設計。
2.2軟件安全設計的先天不足
世界上知名的軟件廠商并不是不了解軟件安全設計安全性的重要性，而是商業模式讓軟件安全方面存在著先天不足。稍縱即逝的商業機會、敏捷的軟件開發過程和短暫的軟件開發周期使得安全性方面的設計在很多時候都是被舍棄的。隨之而來的處理方式則是常見的penetrate-and-pach方法，即不停地補丁。這種做法從長遠來看，其成本與作用遠不及一開始就做好安全性的設計和審計。
3軟件安全設計應引入風險管理
從項目管理的角度看，風險指損失或損害的可能性。軟件項目涉及到的是：項目中可能發生的潛在問題和它們如何妨礙項目成功。風險管理則是對應軟件項目生命周期內的風險的科學和藝術。軟件安全性的設計與軟件設計的其他一些質量性能是互相抵觸的，例如冗余性、高效性。而軟件開發過程中的風險管理與軟件開發的諸如時間、范圍、成本等因素也是相互抵觸的。但是絕不能因為這些可能發生的抵觸行為而放棄對安全性和風險管理的考慮，反而應該將軟件安全性設計納入到風險管理的范疇中去。事實表明，93%的失控項目都忽視了風險管理。
4軟件安全設計風險管理的實施
目前國際上對軟件安全方面的風險管理存在著一個共同的認知，那就是采用高質量的軟件工程的方法論可以在一定程度上解決這方面的問題，歐美一些國家也在試圖制定或修訂相關的一些“通用準則”來指導軟件安全性設計的實踐。但是這只是從科學技術方面做出努力，我們可以學習借鑒。而在管理技術和藝術方面需要做出的努力則應該嘗試本地化做法。完整的風險管理的過程應該包括以下幾個環節：風險管理計劃的編制、風險識別、風險定性分析、風險定量分析、風險應對計劃編制和風險監督控制。將整個流程都走完的項目和企業都不多，一般來自于所謂的學院派。而時下大多數國內外企業的做法是將這個7個流程簡化為誰來識別風險、誰來對風險負責這兩個環節。原因則是上文所提到的先天不足所致。從技術上講，風險管理的效益來自于潛在風險最小化和潛在回報的最大化。而這個技術的應用則一定需要經歷風險定量分析的過程。在這個過程中，可以使用的主要技術是決策樹分析、蒙特卡羅分析、PERT分析等等。這些技術都是建立在一定的數學和會計基礎之上。而令人遺憾的是，很多決策者本身對這些技術的認知或理解欠缺，以至于會抵觸這種方法。大多數做法是采用小團隊開發小軟件的做法，即采用訪談和敏感性分析來幫助風險定量分析。然而我們并不是要反對這種簡化做法，只是一定不能在簡化的做法之上再次簡化或敷衍了事。首先要做的工作是做好需求管理，在建立一組需求輸入的時候，一定要將安全性作為一個重要需求考慮進去。有一個比較好的方法是，在軟件設計時采用螺旋模型，需求的輸入可以在螺旋模型的各個生命周期中進行，而有關安全性的需求輸入則最好是在最初的一個螺旋中進行。之后要做的工作是確定最大風險。不可避免的要使用風險定性和風險定量分析的各種技術和方法。這個工作一定要有軟件設計師、項目決策者和用戶的參與，采用頭腦風暴和專家訪談是不錯的選擇。而這個工作恰恰是現實生活中中小企業乃至客戶最容易忽略的。企業要考慮成本問題，而客戶的參與往往難以落實，認為軟件的設計和開發應該由軟件公司負責，客戶付款只關心最后軟件是否可以使用。而一旦由于軟件安全性問題造成了一定后果后將演變成各種糾纏不清的官司，這是企業和客戶都不想看到的結果。
5結語
篇10
【關鍵詞】建設單位；作用；素質；項目管理
目前在我國建設領域，專業分化越來越細，各類專業業務主體和專業執業資格有幾十種。惟獨對建設單位的工程管理機構和相關從業的相關人員沒有作出具體的、強制的要求，似乎建設單位不需要符合要求的、高素質的管理人才、技術人才和經濟人才，必要的設備和儀器也是可有可無，只要有資金、有項目就是合格的建設單位，就是合格的項目業主。其實恰恰相反，要打造一項優秀的、合格的工程，沒有一支高素質的建設單位管理團隊幾乎是不可能的。一項建設工程，它的投資人是建設單位，收益人也是建設單位，工程要達到的使用功能、規模、標準只有建設單位才能給出準確的定義，工程項目在經濟上是否合理，技術上是否可行，運行使用成本是否低廉且安全可靠，功能是否齊全，是否具有前瞻性，是否符合國家的方針政策，對于這些問題的回答直接關系到工程項目的成功與失敗，這是建設單位必須回答的首要問題，要回答好這些問題，必須具備一定的策劃決策能力，經濟實力和嚴謹的科學方法。規劃和設計是實施工程的龍頭，規劃設計的好壞直接關系到項目決策的目標能否實現，建設單位要有智慧敏銳的眼光在從眾多的方案中尋找最佳的規劃和設計方案，將各方案的優點提煉、歸納、綜合，最后形成一個最完善的規劃設計，要做到這一點必須具備規劃師和建筑師的素質。常有優秀的設計師抱怨，自己的高水平設計沒有被采納，而平庸的設計卻被采用，其實不是建設單位不想要高水準的方案，而是實在看不出孰高孰低，即使高水準的方案就放在眼前，也沒有能力識別。沒有一個高水準的規劃設計方案，那么無論今后的工作做的多么好，這項工程都是低水平低效益的。
根據現行工程建設相關法律法規和建設程序，一項建設工程從立項到竣工驗收交付使用，要經過一系列的階段，過程和程序，相關政府部門對各階段、過程程序都要進行嚴格的審查、監督和管理，先后要辦理立項審批、環境評價、土地規劃許可等數 10 項申報和批復，每道程序都要經過申報、批復和驗收，每到程序又是環環相扣，哪道環節出了問題，下面的程序將很難繼續下去，每道程序的完成都要付出大量的人力物力和財力，這大量的、細致的、繁瑣的工作只能由建設單位自己完成，其他人是無法替代的。有人嘆曰：蓋房子容易，完善手續難！ 以至于有的房子已蓋好，要辦完所有的合法手續，不知等到那年那月！ 有的項目因此成了爛尾樓，而無法收拾。如江蘇某項目，因為沒有合法的環境影響評價報告而全面下馬，前期巨大投入化為烏有。由此可見要使項目獲得成功，建設單位必須精通相關工程建設法律法規，制訂周密的計劃，組織高素質的、知識結構全面的團隊，按照合法的程序盡善盡美的完成每一項計劃工作，才能夠推進工程順利進行。
當前建設工程市場競爭激烈，無論是設計單位、監理單位、工程咨詢單位還是施工承包單位無一列外的卷入這場競爭，建設單位的工程項目成了競爭的終極目標，建設項目是建設工程市場的發動機，如果沒有建設項目，那么設計、監理、施工承包等專業業務單位將難以生存。因此建設單位的各級管理人員成了競爭單位拉攏腐蝕的對象，工程上馬，干部下馬的事件常有發生，，這就需要施工單位的各級管理人員要具備高度的社會責任心，兢兢業業的敬業精神，清正廉潔的風范，公平公正的對待每一個競爭者，建立廉政監督制度，防止腐敗發生，杜絕豆腐渣工程，因此建設單位的各級工程管理人員必須抵抗各種利誘，廉潔奉公的風范、公平公正公開的原則、科學的方法是工程順利完成的重要保證。工程建設是偉大而又艱苦的事業，基本上所有的作業都暴露在大自然中，夏天在烈日當頭下揮汗如雨，冬天在刺骨寒風中辛勤工作，工作環境異常艱苦，工程現場危險因素多多，高空墜落、物體打擊、機械傷害和觸電等傷亡事故時有發生，千防萬防安全事故還是不能完全杜絕。工程建設規模龐大，工程建設又是一個完整的復雜的系統，具有很高的技術含量，每個部位、每道工序檢查一遍，就要付出很大的精力和體力，作為建設單位的工程管理人員必須有強健的體魄、敏捷的身手、敏銳的觀察力和吃苦耐勞的敬業的精神，才能勝任這種環境下的工作。
對于一項建設工程，涉及的政府行政管理監督部門有項目審批、規劃、土地、環保、人防、消防、標辦等眾多機構，參與的合同關系的單位有工程咨詢、規劃設計、地質勘探、工程造價審計、材料供應商等業務單位，在這么多的管理部門和業務單位中，起協調作用和主導管理作用的是建設單位，也只有建設單位才能承擔這個作用，這么多的單位和部門在工程建設項目中發揮各自的不同作用，有審批的，有監管的，有承建的，有咨詢服務的，有材料供應的，可謂千頭萬緒，關系復雜，矛盾重重，一個問題解決不好、一個關系沒有理順都會對工程的進度、質量和造價，造成負面影響，問題的焦點最后都會集中在建設單位。要使建設工程順利進行，保質保量按時完成，把工程造價控制在預算內，必須理順協調各種關系，解決各方矛盾，制訂周密工作計劃和精確進度計劃，籌措充足資金，這就要求建設單位工程管理團隊具有強有力的管理能力，協調能力，溝通能力和經濟實力.要求這個團隊要具有全面的專業知識結構，如果這個團隊缺乏設計監理造價知識，就無法和設計，監理，造價等專業單位溝通，達成理解，如果缺乏招投標和施工知識，就無法將工程發包給有實力的承建單位.不具備全面的專業知識，就無法在工程建設過程中發現問題，解決問題。協調矛盾，實踐證明，一個優秀的工程項目背后一定有一支強有力的管理團隊，而一個爛尾樓是如何管理的就可想而知了。
綜上所述，盡管國家對建設單位的工程管理部門沒有提出具體的資質等級要求，對其從業的工程管理人員、技術人員也沒有提出專業技術職稱等級、執業資格等方面的具體要求，但是要打造一項合格的建設項目，建設單位必須組建一支高素質工程管理團隊，這個團隊要精通工程建設相關法律法規和技術規范，掌握全面的專業知識，要具備一定的管理能力、協調能力、溝通能力和經濟實力，才能勝任艱苦的、細致的、繁雜的工程管理工作。
但是要組建這樣一個專業化的高素質的知識結構全面的建設單位工程管理機構是不現實的，長期以來，我國的建設單位工程管理結構通常是工程指揮部的形式，它隨工程項目的立項而誕生，隨工程項目的竣工而結束，工程管理中的經驗和教訓不能夠得到系統的總結，管理水平難以提高，人員隊伍不穩定，專業性不強，管理成本高昂.依靠建設單位的臨時性指揮部的管理模式，已越來越不能適應工程建設的發展和需要，一種新型的專業化社會化的工程項目管理模式呼之欲出。這就是專業化社會化的工程項目管理公司。
參考文獻：
[1]吳俊，胡昊，李波. 工程建設監理的風險管理[J]. 建筑經濟，2006，（03）：68-72.
[2]吳運華. 建設單位在工程建設中的風險與防范措施[J]. 湖北社會科學，2006，（10）：115-116.
