1=1軟件工程基本原理與信息系統工程項目管理1=1ProjectManagementforInformationSystem

BasedonPrinciplesofSoftwareEngineering

馮-釗FengZanzhao（廣東省水利水電信息中心2002年）【摘要】本文結合作者多年從事信息系統項目策劃和管理的經驗，引申軟件工程原理，分析信息系統工程基本任務，探索項目業主對信息系統項目進行有效管理、順利實現既定目標的一些方法?！娟P鍵詞】軟件工程信息系統項目管理引言國內不少信息系統建設項目都或多或少地經受過“項目泥潭”的痛楚：用戶需求含糊，技術方案粗糙，計劃不嚴謹，管理不規范，工作難協調，實際效果與用戶心目中期望的目標相差甚遠，合同糾紛不斷、一改再改，到后期變得無章可循、各說各理。整個項目就象一個爛泥潭，離竣工日遙遙無期。多數業主單位都不是信息技術本行的，不知如何對信息系統項目進行有效管理，聽任系統開發商的安排。而不少開發商自身就嚴重缺乏有效的管理措施。也有一些業主單位企圖照搬有形工程(如土建工程)建設管理的方法對信息系統項目進行管理，結果往往是令人啼笑皆非。本文結合作者多年從事信息系統項目策劃和管理的經驗，試圖從項目業主的角度出發，探索對信息系統項目進行有效管理、順利實現既定目標的一些方法，希望起到拋磚引玉的作用。信息系統工程與軟件工程毫無疑問，現代信息系統的建設是應用驅動型的，因應業務發展的需要而提出開發各種業務應用軟件，進而確定所需的系統集成方案，即配置怎樣的網絡運行環境，以及它們如何有效地集成在一起組成目標系統。如圖1所示。信息系統建設的成敗主要體現在各種業務應用軟件的運行是否達到預期目的。而“項目泥潭”通常就容易發生在應用軟件的開發和集成上。因此，現代信息系統工程的重點和難點都是軟件工程，軟件工程的基本原理對信息系統工程的建設管理將起主導作用。軟件的主要特點與軟件危機3.1.軟件的主要特點軟件是一種抽象的邏輯實體，其質量問題是隱蔽的。軟件在運行使用中不會磨損和老化，但會退化(過時)。軟件的復雜性使開發人員之間分工困難，增加人手未必能加快進度，卻可能帶來混亂。軟件開發需要投入大量、復雜、高強度的腦力勞動，且至今尚未完全擺脫手工藝的開發方式，因而成本相當昂貴。軟件的開發與運行不僅涉及技術因素，而且相當多地涉及社會因素，涉及機構、體制、管理方式、甚至人的觀念和心理。這些非技術因素直接影響到項目的成敗。軟件危機在計算機軟件技術發展的早期，因程序規模較小，人們心目中只有程序設計的概念，注重個體編程技巧的發揮，缺乏軟件系統的概念。隨著程序規模逐步擴大，功能越發復雜，系統化全局性概念要求越來越高，這與那種任由個體發揮的編程方法之間形成了日益尖銳的矛盾，導致了軟件危機。在西方發達國家，“軟件危機”是1960、1970年代的歷史故事。而在我國，軟件危機卻還是當前時常發生的事情，這就是本文開頭所說的“項目泥潭”。

軟件工程的基本原理約在1970年代以后，許多軟件科學家嘗試把其它工程領域中行之有效的工程學知識運用到軟件開發工作中來，結合軟件技術自身的特點，經過不斷實踐和總結，逐步建立了一套工程化的軟件開發組織管理方法。這就是軟件工程。軟件工程的定義1983年IEEE給出的定義為：“軟件工程是開發、運行、維護和修復軟件的系統方法”。其中，“軟件”的定義為：計算機程序、方法、規則、相關的文檔資料、以及在計算機上運行時所必需的數據的集合。這里尤其要注意“軟件”與“程序”兩個概念的區別。軟件工程包括三個要素：方法、工具和過程。方法為軟件開發提供了“如何做”的技術，包括項目計劃與估算、需求分析、數據結構、系統總體結構的設計、算法過程的設計、編碼、測試以及維護等。工具包括各種軟件工具、開發機器和開發過程信息庫，提供自動或半自動的軟件開發環境。過程定義了方法使用的順序、要求交付的文檔資料、為保證質量和協調變化所需要的管理、及軟件開發各個階段完成的里程碑。這是本文討論的重點。軟件工程過程軟件工程過程是為獲得軟件產品所進行的一系列軟件工程活動，通常包含四種基本的過程活動：P(Plan)：軟件規格說明。規定軟件的功能及其運行限制；D(Do)：軟件開發。產生滿足規格說明的軟件；C(Check)：軟件確認。確認軟件能夠滿足用戶提出的要求；A(Action)：軟件演進。為滿足用戶的變更要求，軟件必須在使用過程中演進。軟件生存周期模型正如任何事物一樣，軟件也有其孕育、誕生、成長、成熟、衰亡的生存過程。我們稱之為計算機軟件的生存周期。根據這一思想，把上述基本的軟件工程過程活動進一步展開，可以得到軟件生存周期的六個步驟。軟件生存周期的瀑布模型如圖2所示。制定計劃：確定要開發的軟件系統的總目標、技術要求、技術和經濟可行性、實施計劃，編制可行性研究報告，提交管理部門審批。需求分析：對待開發的軟件提出的需求進行分析并給出詳細定義，編寫軟件需求說明書或系統功能說明書、以及初步的系統用戶手冊，提交評審。軟件設計：把已確定了的各項需求轉換成一個相應的體系結構，進而對系統內的每個模塊要完成的工作進行具體的描述。編寫設計說明書，提交評審。軟件編碼：即程序編寫，把軟件設計轉換成計算機可以接受的程序代碼。軟件測試：在設計測試用例的基礎上檢驗軟件的各個組成部分。運行/維護：已交付的軟件投入正式使用，并在運行過程中進行適當的維護。實踐表明，上述各項活動之間并非完全是自上而下、呈線性圖式的。實際情況是，每項開發活動均處于一個質量環(輸入-處理-輸出-評審)中。只有當其工作得到確認，才能繼續進行下一項活動，在圖2中用向下的箭頭表示；否則返工，在圖2中由向上的箭頭表示。信息系統項目過程及其各階段任務參照軟件生存周期的瀑布模型，我們可以得出包括業務應用軟件和運行環境網絡平臺在內的一項完整的、綜合型的信息系統工程的生存期模型，如圖3所示。定義階段維璧段需求分析T定義階段(1)制定計劃：由系統分析人員和用戶合作，確定擬建系統的總目標及其功能、性能、可靠性、接口、運

行管理和維護等技術要求；研究技術、經濟和人才的可行性、現有條件和解決問題的可能方案；制定實施計劃、運行管理和維護方案；形成完整的可行性研究報告和投資估算，提交主管部門審批立項。維璧段需求分析T定義階段需求分析：由系統分析人員和用戶合作，深入分析擬建系統的應用需求、軟硬件需求，給出詳細定義，編寫需求分析和系統功能技術說明書以及項目概(預)算書，提交管理部門組織專家評審。通常，建設信息系統的目的是為改善當前業務處理手段。因此，需求分析的任務是要借助當前業務系統的邏輯模型導出目標系統的邏輯模型，對目標系統要“做什么”給出詳細定義。如圖4所示。理解需求-表達需求導出如果系統比較龐大、復雜，甚至涉及多專業業務處理，則應根據不同專業的主要技術特點對總系統進行一級或多級分解，導出每個子、孫系統的目標邏輯模型，并詳細定義它們之間的接口關系。理解需求-表達需求導出在系統功能技術說明書中，對所需的各種設備及其配件、系統軟件、成品軟件、應用軟件、軟件組件的功能技術要求、配置、性能技術指標等應作出全面、詳盡、明確和定量的說明。要注意的是，這些說明應從應用需求角度出發、撇開具體產品型號而提出。這對于需要公開招標的項目尤為重要。此外，對于行業應用軟件的開發或舊系統改造，如果存在某些必須遵守的技術標準或約定，也應在系統功能技術說明書中詳細說明。軟件開發/系統集成階段軟件設計/系統集成設計：軟件設計如前所述。系統集成設計根據審定的系統功能技術說明書，選擇滿足要求、性能價格比優的具體型號產品及其配件，詳細列出軟硬件配置清單，給出詳實的系統集成設計方案和軟硬件采購、安裝調試計劃。軟件設計和系統集成設計并非相互獨立的工作，它們之間的關系非常密切，必須充分溝通和協調。此階段應得到詳實的軟件設計/系統集成設計說明書，交業主組織專家評審。兩者應盡量同時提交給同一批專家評審。軟件編碼/設備采購：根據審定的軟件設計/系統集成設計說明書，分別進行程序編寫和設備采購工作。兩者之間并無太多聯系，但所處時間階段往往大致相同。此外，兩者都屬于生產制造階段，需要特別關注質量控制。尤其對程序編寫，加強程序員的質量意識非常重要。在本階段，因實際運行環境尚未建立，軟件開發單位應自己建立一個能充分模擬實際運行環境的開發環境，在該環境下進行程序編寫。軟件測試/設備安裝調試：兩者之間也無太多聯系，但完成時間最好大致相同，以便能一起進入系統聯合調試。需特別指出，程序代碼中不可避免會存在錯誤，軟件測試的目的不是證明軟件本身無錯或少錯，而是盡可能多地發現錯誤并改正之。測試用例應圍繞這個目的而設計。系統聯合調試：實踐表明，通過了各種測試被認為合格的軟件，集成到實際運行環境時，往往會出現一些意想不到的問題，其主要原因是開發環境與實際運行環境之間不可避免地存在差異。因此，在軟件開發和系統集成的最后階段，應該使兩者集成在一起進行聯合調試，或叫做交工試運行，測試系統各組成部分能否順利結合在一起正常運行，能否達到需求分析階段所確定的目標。系統聯合調試通過后，可進行系統交工驗收，標志一個階段結束?？己诉\行：系統交工驗收后，應安排一段具代表性的時間進行系統考核運行，讓用戶通過實際使用系統，檢驗系統是否實現了建設目標?？己诉\行期長短視系統支持的應用業務性質和復雜性而定?？己诉\行期滿且驗證為合格后，可進行系統竣工驗收。運行維護階段運行/維護：竣工驗收后系統投入正式使用，并在運行過程中根據業務變化的需要進行適當的維護、調整和修改。信息系統項目管理基本方法6.1.項目建設階段管理

目前，信息系統項目建設投資計劃的報批往往是參照有形工程的思路進行的，因此有必要將兩者的項目過程作一些對比，如表1所示。信息系統項目有形工程項目項目建議項目建議可行性研究可行性研究需求分析初步設計招標書編寫招標書編寫招標評標招標評標簽定軟件開/系統集成合同簽定施工合同軟件設計/系統集成設計施工設計程序編寫/設備采購軟件測試/設備安裝調試施工系統聯合調試交工驗收工程投入使用驗考核運行考核運行竣工驗收竣工驗收收信息系統工程的基本原理來源于有形工程，各階段有大致的對應關系，甚至在必要時可以直接借用有形工程相應階段的名稱，但任務內容及所用方法必須保證按信息系統工程自己的特點執行，不可照搬有形工程的任務內容和方法。收兩階段合同管理在需求分析完成且系統功能技術說明書得到批準之前，項目建設的內容和概（預）算都還是不確定的。如果采用一份合同從頭管到尾，則在項目開始所定的合同是一份建設內容不確定的合同，最終會導致“項目泥潭”的結局。因此，不管是否需要招標，都應該分兩個階段簽定合同：第一階段合同的任務是可行性研究、需求分析，其成果主要是書面報告。這相當于有形工程的可行性研究和初步設計合同，合同額只占項目總投資的小部分。第二階段合同的任務是軟件開發/系統集成，其成果是實現具體的目標系統供用戶使用。這相當于有形工程的施工合同，合同額將占項目總投資的大部分。注意如果兩個階段的系統開發商不是同一家，則軟件設計/系統集成設計（相當于“施工設計”）任務應由本階段合同的開發商執行，才能做出切合實際的設計。有了第一階段合同成果的明確定義，第二階段合同的執行就可以避免走向“項目泥潭”。技術文檔與階段評審的重要性隱蔽為主要特征的信息系統工程的每一個階段，都應提交充分的盡可能把需要返工的問題控制在當前階段內，避免跨越一個或多技術文檔應得到及時修訂。智者千慮，必有一失。以抽象、技術文檔，供用戶和專家詳細評審，個階段的返工。當具體情況改變時，隱蔽為主要特征的信息系統工程的每一個階段，都應提交充分的盡可能把需要返工的問題控制在當前階段內，避免跨越一個或多技術文檔應得到及時修訂。有些開發商總想以最少的工作量盡快把合同款項賺到手，不愿認真進行各階段詳細文檔的編制和評審，結果從頭到尾積累了一大堆問題需要跨階段返工，到最后反而可能要賠本。項目管理者必須對這種“偷工減料”的情況進行嚴格監控。項目監理的必要性信息系統工程建設監理是近兩年才提出來的，目前尚在探索中，不象有形工程建設監理制度那樣完善。從先行者的探索經驗來看，這是很有必要而且成效顯著的。在目前條件下，可以雇請有直接開發經驗的人員充當監理角色，幫助業主監管項目建設的整個過程。結語信息系統工程原理來源于有形工程，但又明顯區別于有形工程。項目管理人員應該按信息系統工程的特點嚴格把握各階段的任務以及衡量其完成