系統整合專案是根據使用者的需求、優選各種技術產品，進行設計開發，將各個分離的「資訊孤島」連線、集成為乙個完整、可靠、經濟和有效的整體，並使之能彼此協調工作，發揮整體效益，達到整體優化的目的。
由於典型的系統整合專案具有目標不明確、需求變化頻繁、智力密集、設計人員高度專業化、涉及的承包商多等特點；在系統整合專案中，由於使用者的不同需求和特點，每乙個系統整合專案都和其他工程不完全一樣，因此需要一定的定製，帶有一些非標準的問題，加之系統整合專案要求對使用者需求有較好的掌握，所有這些因素就造成了對資訊系統建設的複雜性。、
資訊系統的生命週期可以分為四個階段：形成、開發、運維和消亡。
典型的資訊系統有軟體子系統、資料庫子系統和網路子系統組成。所以應在資訊系統的早期明確對資訊系統的需求，並把這些系統分配給軟體子系統、資料庫子系統和網路子系統。
● 形成階段包括概念形成（問題定義）、可行性分析和需求調研。
● 開發階段包括需求分析、系統設計、系統實施和系統驗收等子階段。
● 運維階段包括保證系統正常。
當資訊系統不可避免的會遇到更新改造、功能擴充套件、甚至報廢重建等情況時，資訊系統就進入消亡階段。典型的資訊系統的生命週期如圖，其中驗收之前的工作稱作專案或工程，驗收之後稱為系統的執行和維護。
圖3.1 典型的資訊系統生命週期
資訊系統建設的原則如下：
● 為客戶的業務發展服務
● 總體規劃、分步實施
● 保護客戶現有的（it資產）（與客戶現有的系統和資料相容、互聯互通)
● 支援soa架構
常用的資訊系統分析與系統設計的方法有：結構化方法和物件導向的方法。
常用的過程方法有：瀑布模型、螺旋模型、原型法和迭代法。
適用於專案需求清晰，在專案初期就可以明確所有需求、不需要二次開發的軟體生命週期模型是瀑布模型；適用於專案實先不能完整定義產品需求、計畫多期開發的軟體生命週期模型是迭代模型。
一般把資訊系統專案的生命週期劃分為啟動、計畫、實施和收尾等四個典型的階段，監控作為過程貫穿於整個生命週期，而資訊系統作為專案的產品也可按技術工作劃分產品的生命週期，按個生命週期按時間的先後，以過程的方式相互穿插在一起。
瀑布模型、迭代模型和快速原型開發是典型的三個產品的生命週期模型。
對需求清晰、在專案初期就可以明確所有的需求、不需要二次開發的專案而言，瀑布模型適合用來做產品的生命週期模型。
對於事先不能完整定義產品所需需求、計畫多期開發的專案來說，迭代模型適合用來做產品的生命週期模型。
對於需要很快給客戶/使用者演示產品原型的專案，快速原型開發適用於做產品的生命週期模型。
習題三在軟體開發的v模型中，應該在概要設計階段制定系統的測試計畫。
瀑布模型把測試推遲到專案生命週期的最後階段進行，系統前期出現的嚴重錯誤可能被隱藏，此時修改代價很大、發布日期會被迫延遲，而且瀑布模型使得開發中的很多關鍵成員例如開發人員和測試人員長期處於空閒狀態。「v模型」可以稱為瀑布模型的變形模式，它提出了測試提前的理念。
v模型如圖3.2所示
圖3.2的左邊是設計和分析，是軟體設計實現過程，同時伴隨著制定測試計畫的過程；右邊是對左邊結果的驗證，即對設計和分析的結果進行測試，以確認是否滿足使用者需求。如：
● 需求分析對應驗收測試。在做需求分析、產品功能設計的同時，測試人員就開始閱讀、審查需求分析結果，從而了解產品的設計特性、使用者的真正需求，確定測試目標，可以準備用例並制定驗收測試計畫。
● 當系統設計人員在概要設計時，測試人員可以了解系統是如何實現的，基於甚麼樣的平台，這樣可以設計系統測試方案和系統測試計畫，並事先準備系統的測試環境，包括硬體和第三方軟體的採購。
需求分析驗收測試
概要設計系統測試
詳細設計整合測試
編碼單元測試
● 當設計人員在做詳細設計時，測試人員可以參與設計，對設計進行評審，找出設計的缺陷，同時設計功能、新特性等各方面的測試用例，完善測試計畫，並基於這些測試用例並開發測試指令碼。
● 在程式設計的同時，進行單元測試，是一種很有效的辦法，可以盡快找出程式中的錯誤，充分的單元測試可以大幅度提高程式質量，減少成本。
習題四rup是資訊系統專案的生命週期模型之一，「確保軟體結構、需求、計畫足夠穩定；確保專案風險已經降低到能夠預計完成整個專案的成本和日程的程度。針對專案軟體架構上的主要風險已經解決或處理完成細化階段的主要任務。
rup（rational unified process）軟體統一過程是一種」過程方法「，它就是迭代模型的一種。rup中的軟體生命週期在時間上分解為四個順序的階段，分別是：初始階段、細化階段、構建階段和交付階段。
這四個階段的順序執行就形成乙個週期。
其中細化階段的任務如下：
（1）確保軟體結構、需求、計畫足夠穩定；確保專案風險已經降低到能夠預算完成整個專案的成本和日程的程度。
（2）針對專案的軟體結構上的主要風險已經解決或處理完成。
（3）通過完成軟體結構上的主要場景建立軟體體系結構的基線。
（4）建立乙個包含高質量元件的可演化的產品模型。
（5）說明基線化的軟體結構可以保障系統需求可以控制在合理的成本和時間範圍內。
（6）建立好產品的支援支撐。
極限程式設計技術xp適用於需求多變，開發隊伍規模較小，需求開發方」快速反饋，及時調整「。
極限程式設計技術xp是一種開發軟體的輕量級方法。xp適用於小型或中型軟體開發團隊，並且客戶的需求模糊或需求多變。
xp是一種近螺旋式的開發方法，它將複雜的開發過程分解為乙個個相對比較簡單的小週期。通過積極的交流和反饋，可以根據實際情況及時的調整開發過程。
1、資訊系統需求調研與系統分析
通過需求調研要搞清楚如下問題：
客戶對待建系統有那些要求？使用者的業務目前是如何開展的？目前存在甚麼問題？
業務及其流程是否需要優化？使用者的那些業務需要it技術支援？使用者業務的那些問題需要it技術倆解決？
此時客戶和使用者的語言類描述客戶的需求和使用者的業務，用客戶和使用者的語言來與他們進行交流的並與他們達成一致的認識。
通過需求分析（或者稱之為系統分析），要把需求調研的結果用it語言或通俗的圖形描述出來，要回答如下問題：
未來要開發的系統應該具有那些功能和效能？它有甚麼樣的系統架構？每乙個功能模組有時如何支援客戶需求和使用者業務的？對系統的可用性、可靠性、可移植性、整合性、適應性和資料要求是甚麼？
上述過程提及的描述語言是統一建模語言（uml）。ｕｍｌ提供了通俗的符號和圖形來描述客戶的需求和使用者眼中的業務，uml以圖形的方式方便了it人員、客戶和使用者之間的交流。
對軟體專案和軟體子專案來說，rup可以參考的開發方法之一，rup對網路工程也有很強的指導作用。
2、資訊系統的設計
由於資訊系統由線路、網路、軟體和資料庫組成，因此無論是資訊系統的需求調研、需求分析（或稱系統分析）還是資訊系統的設計，都涉及到綜合佈線、組網和軟體系統（含資料庫）等三部分，這三部分分別承擔客戶和使用者對資訊系統的相應需求。
1關於三部分的設計工作，下文都會有論述。
1)方案設計
資訊系統的方案設計包括如下內容：、
（1）資訊系統的總體設計
（2）軟體工程的設計
（3）網路工程的設計
（4）綜合佈線和機房工程設計
有關軟體工程的設計請參考3.3.3節和3.
4.5節相關的內容，有關網路工程的設計、綜合佈線和機房工程的設計和裝置、dbms和技術選型。請參考3.
7.11節中的相關內容。
2）系統架構
典型的資訊系統體系結構如下圖3.3所示
在圖3.3中，環境支援平台包括機房和電源，環境支援平台也叫基礎設施。計算機網路平台包括網路傳輸基礎設施、網路通訊裝置、網路伺服器和作業系統、網路協議、網路平台、外部資訊基礎裝置等，以保證網路的互聯互通、應用基礎平台包括資料庫平台、internet基礎服務、網路管理平台和開發工具等。
網路應用系統層放置為使用者的業務開發出來的各種應用軟體系統使用者介面層包括為使用者開發的客戶/伺服器client介面、web介面和gui介面。
在圖3.3中，網路安全是指在網路系統中保證資訊產生、處理、傳輸、儲存過程中的機密性、鑑別、完整性和可用性的軟硬體措施，它可能貫穿與網路體系結構的每乙個層次。除網路安全技術之外，還需要對網路進行安全管理，網路安全管理是乙個組織建立資訊保安方針和目標實現這些目標的體系。
軟體需求分析與定義過程了解客戶需求和使用者的業務，為客戶、使用者和開發者之間建立乙個對於待開發的軟體產品的共同理解，並把軟體需求分析結果寫到《軟體需求說明書》中。
1、需求分析的任務
需求分析的任務是：準確定義未來系統的目標，確定為了滿足使用者的需求待建系統必須做什麼即」what to do?」,並用需求規格說明書以規範的形式準確表達使用者的需求。
讓使用者和開發者共同明確待建的是乙個甚麼樣的系統，關注待建的系統要做甚麼，應具備甚麼樣的功能和效能。需求分析有兩個任務：
● 建立分析模型
● 編寫需求規格說明書
需求分析的步驟如下：
● 需求獲取
● 需求提煉
● 需求描述
● 需求驗證
乙個典型的、傳統的結構化的需求分析過程形成的軟體需求說明書包括如下內容：
1、前言
1.1目的
1.2範圍
1.3定義、縮寫語、略語
1.4參考資料
2、軟體專案概述
2.1 軟體產品描述
2.2 軟體產品功能描述
2.3 使用者特點
2.4 一般約束
2.5 假設和依據
3、具體需求
3.1 功能需求
3.1.1功能需求1
3.1.1.1引言
3.1.1.2輸入
3.1.1.3加工
3.1.1.4輸出
3.1.2 功能需求2..
. 功能需求n
3.2 外部介面需求
3.2.1 使用者介面
3.2.2硬體介面
3.2.3 軟體介面
3.2.4 通訊介面
3.3效能需求
3.4 設計約束
3.4.1 其他標準的約束
3.4.2 硬體的限制..
.3.5屬性
3.5.1 安全性
3.5.2可維護性..
.3.6其他需求
3.6.1資料庫
3.6.2 操作
3.6.3 場合適應性
對上述的部分款項，解釋如下：
1.2 範圍要明確專案軟體產品的名稱、用途和應用
2專案概述描述影響產品和其需求的一般因素，不說明具體的需求，而僅使需求更易於理解。進一步說明如下：
2.1軟體描述說明產品是不是獨立的、全部內容自含的，說明軟體產品的功能和效能、設計限制、屬性（可移植性、正確性、可維護性及安全性等）、外觀介面。
2.2 產品功能為將要完成的軟體功能提供乙個摘要。
企業資訊系統整合研究
作者 劉龍 科技與企業 2013年第03期 摘要 隨著世界市場的不斷形成，企業間的競爭逐漸激烈。實現企業的資訊化是企業提公升自身競爭力的乙個有效途徑，為此，筆者對該問題進行了系統的說明，以全面提公升我國企業的綜合競爭實力。關鍵詞 企業 資訊化 應用系統 整合 前言當今世界已經逐漸成為乙個資訊時代，各...
資訊系統整合專案管理問題分析
3專案管理問題略析 3.1專案範圍管理欠缺 1 問題的提出 許多系統整合公司承建的系統整合專案有過這樣的經歷 乙個專案做了很久，感覺總是做不完，就像乙個 無底洞 客戶總是有新的需求要整合商做，就像客戶在 漫天要價 而系統整合公司則總是疲於應付，從而帶來專案週期拖長 專案成本超出預算 客戶滿意度降低 ...
通訊資訊系統整合服務合同
目錄第一部分協議書 第二部分合同條款 一 通用條款 第一章詞語定義及解釋 第二章甲方代表 第三章乙方代表 第四章甲方工作及責任 第五章乙方工作及責任 第六章專案造價 第七章專案施工質量管理 第八章週期管理 第九章專案現場管理 第一十章材料與裝置 第一十一章設計變更 專案指令 簽證及專案聯絡單 第一十...