第一篇：軟件工程理論的信息工程監理研究論文

【摘要】隨著社會的不斷發展，信息工程在現代企業中的作用和意義愈加明顯。在信息工程當中，主要包括信息應用工程、信息網絡工程、信息資源工程等內容。而在信息工程監理方面，隨著軟件工程的發展和應用，使其更加的直觀、系統，對于監理水平、監理效率的提升，發揮了重要的推動和促進作用。基于軟件工程理論，可以研究和建立更為良好、適當的管理模式，從而更加深入、高效的對信息工程進行監理。

【關鍵詞】軟件工程；信息工程；監理

中圖分類號：TP311文獻標識碼：A文章編號：1006-4222（2015）24-0316-02

前言

隨著社會經濟和科技的不斷發展，信息工程得到了極大的發展，在基礎設施建設、系統建設等方面，都取得了較為巨大的進步。各個企事業單位，甚至政府機關部門對于信息工程監理的重視程度都在不斷提高。在信息工程當中，通常都較為龐大、復雜，具有技術要求高、工期長、投資大、風險高等特點。因此，在信息工程當中，監理的作用不容忽視。隨著軟件技術的發展，基于軟件工程理論，能夠更加有效的進行信息工程監理，從而確保信息工程的順利進行。

1信息工程的概述

信息工程是基于現代計算機技術、超大規模集成電路技術等，對信息處理的理論、技術和實現進行研究。信息工程技術的核心是控制系統和信息系統，在現代化社會的發展中，具有十分重要的作用。相比于一般的工程項目，信息工程具有較高的復雜程度和較低的能見度等特點。在信息工程項目當中，組織和建設之間存在著密切的聯系[1]。根據項目組織的要求，信息工程應當遵循一定的組織思維過程，即前期準備、項目規劃、項目設計、項目實施、項目驗收、項目維護的過程。通過對這些組織標準的嚴格設立和執行，建立相應的技術標準。以組織需求為基礎帶動技術需求，并根據組織滿意度來對技術滿意度進行評價。與其它種類的工程不同，信息工程要求建設單位必須全員全程進行參與。究其原因，是因為信息工程項目具有較高的復雜程度，在傳遞知識的過程中，具有較為繁瑣的步驟。因此，建設單位必須進行全員學習和了解，以掌握相關的知識技能。在開發單位和建設單位之間，應當實現協同共進、相互協調和相互適應。信息工程系統具有人機結合的特點，因此，如果建設單位沒能夠實現良好的全員全程參與，系統的全面性、完整性、有效性等都會受到一定的影響。在信息工程項目當中，通常具有十分復雜的需求，因此，其可見性無法達到其它工程項目的程度。不但檢驗過程復雜，維護期也比較長。另外，再加上一些非技術因素的影響，很可能造成信息化項目建設的失敗[2]。

2信息工程監理的意義

目前，在我國眾多企業當中，實現信息工程項目的成功幾率較為有限。針對信息工程項目的自身特點，為了提高其成功的幾率，就應當及時建立良好的信息工程，采用第三方監理單位，在信息工程項目建設的過程中，進行嚴格的監理。對于企業和開發單位之間的協調，信息工程監理能夠發揮出良好的作用，從而確保信息工程項目能夠順利的開展。目前，我國很多企業信息工程監理都參考了傳統建筑工程中的監理模式。但是具體來看，其與建筑工程監理之間，還存在著一定的差異。這是由于信息工程具有很低的可見度，擁有極高的知識密集度和復雜多變的開發過程。在其它的建筑工程項目監理當中，能夠對施工現場的進度、質量等進行實時的監督和管理。但是在信息工程監理中，無法實時監督和管理其操作質量和操作現場[3]。因此，信息工程當中的軟件質量、建設進度、資金使用情況、合同執行情況等，在操控和把握過程中都具有很大的難度。正是由于這種現象，造成了信息工程監理操作度低、復雜度高、能見度低等問題。在監理過程中，為了能夠有效的解決和處理這些問題，應用軟件工程理論是一種非常有效的方法。基于軟件工程，能夠有效的分解復雜度較高的信息工程項目，同時可采取有效的方案解決信息工程中能見度低的問題。利用當前現有的軟件工程工具和平臺，能夠針對信息工程監理中存在的問題，提供一個相應的監理平臺，從而提高監理的可見性、降低復雜度，對于我國信息工程的發展具有十分重要的意義。

3信息工程監理

3.1監理目標

在軟件工程當中，主要的任務在于對科學有效的管理方法進行充分的應用，從而不斷的提升軟件開發的質量。軟件工程的主要意義在于改變傳統小作坊式的軟件開發模式，并且對其進行詳細的分解和劃分，根據各個具有不同特點的階段，分別采用不同的工具和方法，在具有較高復雜程度的軟件生產過程當中，進行可控制和可度量的有效設置[4]。通過有效、嚴格的對各個不同階段進行控制，在前期階段，就能夠及時的發現可能出現的風險和存在的隱患，并且進行及時的處理和解決。這樣，軟件開發過程中的風險就能夠得到有效的控制，最終實現提升軟件質量的目的。在信息工程監理當中，科學、有效的規劃和控制信息工程的投資、質量、進度等方面的情況，是信息工程監理最為重要的目的和意義。基于軟件工程理論，在信息工程監理的過程中，通過對合同的有效管理，進行有效的協調和組織，從而實現動態的控制工程，最終完成理想的目標規劃。在前期準備、項目規劃、項目設計、項目實施、項目驗收、項目維護的整個信息工程項目過程中，確保信息工程監理能夠貫穿始終。通過有效的合同管理、信息管理、成本控制、進度控制、質量控制，信息工程監理能夠確保信息工程順利、高效的開展，并且保證信息工程的良好質量。

3.2監理模型

從信息工程監理的目標當中來看，可對信息工程項目進行劃分，主要包括項目分析、項目設計、項目實施、項目維護等不同階段。基于軟件工程理論的信息工程監理，并不是對軟件工程的相關理論機械的復制和應用到信息工程監理當中，而是應當結合軟件工程理論的相關內容，有效的管理和設計能見度低、復雜度高的信息工程項目[5]。在信息工程監理當中，將其進行有效的融合應用。通過這種方式，基于軟件工程理論，可以進行信息工程監理模型的建立。在監理模型當中，其主線是信息工程項目的過程控制，在信息工程當中，全方位的監督和控制項目分析、項目設計、項目實施、項目維護等不同階段中的工作。同時進行有效的需求管理、信息管理、合同管理、風險管理，以及成本控制、治理控制、進度控制。此外，還需要對信息工程進行總體性的良好協調。基于軟件工程理論，對這些工作進行系統的整合，從而形成了三控四管一協調的三維監理模型，對信息工程進行更為有效的監理。

4結論

在當前社會中，軟件工程是一種十分有效的工程，利用工程化的方式和手段，對軟件開發和生產進行更為有效的管理，從而提高軟件的質量。在信息工程當中，軟件工程能夠對其監理工作帶來巨大的啟示。針對信息工程監理中存在的復雜度高、可見度低等難題，基于軟件工程基礎，建立信息工程監理模型，為信息工程提供一個可見度高、復雜度低的監理平臺，從而更好的監督和控制信息工程建設，最終確保信息工程的質量和進度。

參考文獻

[1]申勝利，周舟，賈萍，張垚垚.基于CMM的信息系統工程監理研究與實踐[J].國土資源信息化，2010，06：122~125+112.[2]管東升，呂小剛，趙云豐.基于能力成熟度的信息系統監理過程改進研究[J].計算機技術與發展，2011，01：137~139+146.[3]劉宏志，鄧小云，劉宣旭，張斌，毛典輝.基于可拓集的軟件工程安全監理的研究[J].計算機安全，2011，12：32~35.[4]韓福霞，劉宏志.基于蝙蝠算法的信息工程監理多目標優化研究[J].現代計算機，2013，19：3~6.[5]吳丹，劉宏志，李偉，舒彬，尹璐.基于FPN的電力信息工程監理服務質量評價研究[J].電氣應用，2015，S1：305~309.

第二篇：工程信息監理實施細則

工程信息監理實施細則

監 理 實 施 細 則

工程名稱0

專業名稱 工 程 信 息

編 制 人

總 監

.工程信息監理實施細則

目 錄

一、工程概況及專業特點

二、監理實施細則編寫依據

三、監理工作內容

四、施工資料的審查

五、監理信息和資料的收集

工程信息監理實施細則

一、工程概況及專業特點

1、工程規模 0

三、監理工作內容

1、制定監理工作制度和工程報驗規定，對施工單位進行交底；

2、參與編制各工程項目的監理實施細則；

3、審查施工單位及人員上崗資質，對施工機械設備進場報審資料的有效性進行檢查；

4、審查進場原材料、構配件質量保證資料，嚴格材料復試及報驗手續，要求按頻率進行抽測；

5、嚴格工序報驗程序，審查報驗資料的真實性、同步性、完整性，并及時進行監理實測，簽證合格工程量；

6、及時發送工地例會、安全例會及其它專題會議會議紀要；

7、編制監理旬、月（半）報，對工程質量、進度情況進行統計、分析，對監理工作進行總結和安排；

8、定期或不定期向業主匯報工程質量、進度及存在問題等有關情況；

9、及時簽發監理指令，對工程質量、進度、安全文明施工等方面進行嚴格監控；

10、審查施工單位工程進度款申請表，開具工程款支付證書，進行投資控制；

11、記錄大事記及監理日記，積累監理資料；

工程信息監理實施細則

12、審查施工單位竣工資料（特別是質量保證資料），按業主及有關的歸檔要求進行施工和監理資料的整理和歸檔；

13、及時提交工程質量評估報告；

14、及時向業主報送監理工作總結。

四、施工資料的審查

在現場監理工程師日常簽證審查的基礎上，信息監理工程師每旬對施工資料進行一次全面檢查，主要檢查內容如下：

1、工序報驗資料

按單元工程的劃分進行報審，報審資料要求清晰、規范，檢查項目齊全；檢測項目的檢測頻率要滿足《水利工程施工質量檢驗評定標準》（試行）的要求，施工及監理相關人員簽證意見明確，不得代簽，檢查的合格點及合格率計算無錯誤，無涂改，報驗資料要求分類清楚，保存完好。

2、隱蔽工程驗收記錄驗收資料

隱蔽工程驗收記錄內容齊全、圖示規范、尺寸清晰，檢查內容記錄詳細。施工單位有關人員簽證意見明確，監理驗收意見明確，用語規范。

3、材料、設備、構配件報審資料

對材料的供應單位相關資料要求實行審查。施工單位應提供相關證明，準用證為上海市建材業管理辦公室監制的連號防偽復印紙，交易會員證、出廠合格證。質保單如不是原件，則應滿足復印件要求。信息監理工程師定期或不定期對所有質保資料進行全面檢查。

工程信息監理實施細則

4、檢測計量施工機械設備報審資料

工程設備應注明出廠日期，設備的型號、數量及相關的檢驗校核證書。

5、構配件報審資料

對構件生產廠家生產資質證書文件進行審查，現場監理存復印件，證明文件為營業執照，生產許可證，質量監督證，試驗室資格等級證書等。到場構配件具備相應的出廠質量證明書。

6、工程變更資料

由設計單位下達的設計修改通知單，出圖手續齊全，業務聯系單應通過監理、設計及建設單位的簽證認可方可實施。

7、竣工資料的整理

竣工后，及時對竣工資料進行審查，竣工報驗手續齊全，竣工圖的編制要符合有關規定，并有相關的編制說明。

8、水利工程資料歸檔必須完整、準確、系統。按建設單位下達的歸檔目錄和有關要求進行整理，做到字跡清楚，圖面整潔、裝訂整齊、簽字手續完備。

五、監理信息和資料的收集

1、監理規劃和實施細則

監理規劃是整個監理工作的指導性文件，經公司總工程師審批后加蓋公司公章。監理實施細則按規劃要求，按工程結構的不同形式和不同專業編制相應的監理實施細則，經總監審批加蓋監理部公章。

2、會議紀要

工程信息監理實施細則

工地會議（工程例會、安全專題會議、施工協商會及其它專題會議）會議紀要要準確表達與會各方的意見，與會人員簽到，及時整理會議紀要，重要的議題需要經過各方簽認形成決議，作為執行和檢查的依據。及時傳達有關各方。

3、監理旬、月報

監理周、月報是監理部向業主報告當月各工程項目的施工和監理工作的具體情況，記錄工程建設各種大事紀要，內容如下；

1）工程施工情況

對工程施工質量、進度進行客觀的描述，施工過程中出現質量問題產生的原因及處理措施。進度情況應說明詳細的位置以及與計劃進度的對比情況。對工程進度進行全面的分析和提出合理的建議。

2）工程質量驗收和簽證情況。

4、專題報告

1）針對工程進展情況，對施工節點的完成進行分析，提出存在問題和合理建議。

2）匯報現階段監理工作情況。3）匯報與本工程有關的問題。

5、工程實施過程的監理資料

1）監理指令包括聯系單、通知單、工程暫停令

2）監理復核記錄，對施工測量放樣及竣工斷面復核記錄。3）工序驗收監理復核記錄，對照施工單位報審資料，對工程質量進行實測檢查和驗收。

工程信息監理實施細則

6、質量評估報告

對工程施工質量進行客觀的評估，并提出質量評定等級的建議。主要內容包括：

1）工程概況；

2）工程施工質量評估主要依據 3）施工過程的質量控制 4）工程施工質量評估 5）結論

7、監理工作總結

工程結束后，及時向業主報送監理工作總結，主要內容包括： 1）工程概況

2）監理組織機構、監理人員和投入的監理設施 3）監理合同的履行情況 4）監理工作成效

5）施工過程中出現的問題及處理情況和建議

8、音像資料的整理和收集 1）工程照片資料

為了更好的控制施工質量詳細記錄施工進展全過程，對施工進行動態監控，為將來工程管理提供完整而可靠的施工監理資料，將采用數碼照相機和攝像機進行全方位的跟蹤記錄。

按照工程結構的不同，將工程照片信息資料收集如下： ①防浪墻拆建工程：老墻拆除；墊層澆筑；墻體澆筑。

工程信息監理實施細則

②堤頂道路工程：墊層、基層鋪設；瀝青砼澆筑；鋼筋砼小擋墻澆筑。

③大堤護坡、護腳加固工程：四角空心塊預制；柵欄板及格埂加高、拋石施工；塊石理砌。

④防汛鋼閘門工程：鋼閘門制作；鋼閘門導軌安裝。⑤內坡護坡工程：草皮護坡；排水溝；青坎。2）影像資料 ①工程類

配合數碼相機對工程的重要工序或部位的施工進行全過程的拍攝，對工程原始狀況及重要節點的完成情況進行采集，通過對資料的加工、整理，制作成光盤存檔。

②會議類

主要收集工地例會、安全例會及其它施工方案評審、工程協商等專題會議的現場情況，對有關單位的現場檢查及工程重大儀式進行真實的記錄。

第三篇：信息工程監理合同

給監理方造成的經濟損失，累計賠償額不應超過監理費總額。監理方處理委托業 務時，因非監理方原因的事由受到損失的，可以向委托方要求補償損失。第三十一條 委托方如果向監理方提出賠償的要求不能成立，則應當補償由該索賠所引起的監理方的各種費用支出。

合同生效、變更與終止

第三十二條 由于委托方或承包方的原因使監理工作受到阻礙或延誤，以致發生了附加工作或延長了持續時間，則監理方應當將此情況與可能產生的影響及時書面通知委托方。完成監理業務的時間相應延長，并得到附加工作的報酬，具體內容雙方再行商議并簽署補充協議。

第三十三條在委托監理合同簽訂后，實際情況發生變化，使得監理方不能全部或部分執行監理業務時，監理方應當立即書面通知委托方。雙方確認該監理業務的完成時間應予延長。當恢復執行監理業務時，應當增加不超過10個工作日的時間用于恢復執行監理業務，并按雙方約定的數量支付監理報酬。

第三十四條本合同終止條件：

1、因客觀原因造成的實施工作和監理工作不能按合同規定履行，經監理方與委托方、承包方協商后，雙方同意終止合同，雙方簽署終止合同文件，本合同即終止。

2、按本合同規定項目正常完成，承包方與委托方完成最終驗收和工程移交手續后，監理方按本合同規定移交完所有監理文件，本合同即終止。

第三十五條 當事人一方要求變更或解除本合同時，應當在10個工作日內通知對方，因解除合同使一方遭受損失的，除依法可以免除責任的外，應由責任方負責賠償。變更或解除合同的通知或協議必須采取書面形式，協議未達成之前，原合同仍然有效。

第三十六條監理方在應當獲得監理報酬之日起7天內仍未收到支付票據，委托方又未對監理方提出任何書面解釋時，或根據第三十四條及第三十五條已暫停執行監理業務時限超過一個月的，監理方可向委托方發出終止合同的通知，發出通知后7日內仍未得到委托方答復，可進一步發出終止合同的通知，如果第二份通知發出后，三個工作日內仍未得到委托方答復，可單方面終止合同或自行暫停或繼續暫停執行全部或部分監理業務。委托方承擔全部違約責任。

第三十七條 監理方由于非自己的原因而暫停或終止執行監理業務，其善后工作以及恢復執行監理業務的工作，應當視為額外工作，有權得到額外的報酬（可參考三十二條）。

第三十八條 當委托方認為監理方無正當理由而又未履行監理義務時，可向監理方發出指明其未履行義務的書面通知。若委托方發出通知后7日內沒有收到答復，可在第一個通知發出后10日內發出終止委托監理合同的通知，合同即行終止。

違約責任

第三十九條 由監理方單方面的原因造成的違約責任，監理方承擔賠償責任（參考第二十五條和第二十七條），賠償的最高限額不超過該工程監理服務合同款的50%；由委托方單方面的原因造成的違約責任，由委托方承擔賠償責任（參考第三十條）。

監理報酬

第四十條 正常的監理工作、附加工作和額外工作的報酬，按照監理合同專用條件中第八條的方法計算，并按約定的時間和數額支付。

第四十一條 如果委托方在規定的支付期限內未支付監理報酬，自規定之日起，還向監理方支付滯納金。滯納金按如下方式計算：

滯納金=拖欠金額×支付期限最后一日銀行貨款利率×拖欠時間累計(滯納金按每天千分之5收取)

第四十二條 支付監理報酬所采取的貨幣幣種、匯率由合同專用條件約定。第四十三條 如果委托方對監理方提交的支付通知中報酬或部分報酬項目提出異議，應當在收到支付書面通知書24小時內向監理方發出表示異議的通知，但委托方不得拖延其他無異議報酬項目的支付。

其它

第四十四條 在監理業務范圍內，如需聘用專家咨詢或協助，由監理方聘用的，其費用由監理方承擔，由委托方聘用的，其費用由委托方承擔。

第四十五條 監理方在監理工作過程中提出的合理化建議，使委托方得到了經濟效益，委托方應按專用條件中的約定給予經濟獎勵。

第四十六條 監理方駐地監理機構及其職員不得接受監理工程項目施工承包方任何報酬或者經濟利益。監理方不得參與可能與合同規定的與委托方的利益相沖突的任何活動。

第四十七條 監理方在監理過程中，不得泄露委托方申明的秘密，監理方亦不得泄露設計方、承包方等提供并申明的秘密。

第四十八條 監理方對于由其編制的所有文件擁有版權，委托方僅有權為本工程使用和復制此類文件，不得將此類文件外傳至與本工程無關的機構或個人，否則監理方有權追究法律責任。

爭議的解決

第四十九條 任何一方因違反合同的規定而引起責任糾紛和損害賠償，雙方應當協商解決，如未能達成一致，可提交主管部門協調，如仍未能達成一致時，根據權力約定提交仲裁機關仲裁，或向人民法院起訴。

第三部分 信息系統工程監理專用條件

第一條 本合同使用的法律及監理依據：

(1)國家信息產業部、建設部的有關規范；

(2)《中華人民共和國技術合同法》；

(3)本合同生效后若出現國家有關法律、法規變化，本合同應根據國家有關法律、法規作相應調整。

第二條 監理機構：

總監理工程師

第三條 委托方應提供的工程資料及提供時間：

(1)設計文檔、招標文件、施工方投標文件、工程合同、現場資料（包括原始資料）等；

(2)委托方提供文件目錄，文件號，文件正本，保密資料注明密級；監理方代表簽收文件，確認簽收日期；工程完工后監理方交還以上資料，委托方代表簽收并確認交還日期。

第四條委托方應在回復期限內對監理方書面提交并要求作出決定的事宜作出書面答復，特殊情況下可先口頭或電話答復并即補書面答復。書面答復在送達監理方時生效，收受方應用書面回執確認。若超過約定期限監理單位服務方未收到委托方的決定意見，可理解為委托方對監理方的明確建議意見無異議，并將該建議意見視為委托方的決定。委托方對監理方書面提交的要求決策的文件的回復期限：

(1)一般文件5個工作日；

(2)緊急事項報告文件2個工作日

給監理方造成的經濟損失，累計賠償額不應超過監理費總額。監理方處理委托業 務時，因非監理方原因的事由受到損失的，可以向委托方要求補償損失。第三十一條 委托方如果向監理方提出賠償的要求不能成立，則應當補償由該索賠所引起的監理方的各種費用支出。

合同生效、變更與終止

第三十二條 由于委托方或承包方的原因使監理工作受到阻礙或延誤，以致發生了附加工作或延長了持續時間，則監理方應當將此情況與可能產生的影響及時書面通知委托方。完成監理業務的時間相應延長，并得到附加工作的報酬，具體內容雙方再行商議并簽署補充協議。

第三十三條在委托監理合同簽訂后，實際情況發生變化，使得監理方不能全部或部分執行監理業務時，監理方應當立即書面通知委托方。雙方確認該監理業務的完成時間應予延長。當恢復執行監理業務時，應當增加不超過10個工作日的時間用于恢復執行監理業務，并按雙方約定的數量支付監理報酬。

第三十四條本合同終止條件：

1、因客觀原因造成的實施工作和監理工作不能按合同規定履行，經監理方與委托方、承包方協商后，雙方同意終止合同，雙方簽署終止合同文件，本合同即終止。

2、按本合同規定項目正常完成，承包方與委托方完成最終驗收和工程移交手續后，監理方按本合同規定移交完所有監理文件，本合同即終止。

第三十五條 當事人一方要求變更或解除本合同時，應當在10個工作日內通知對方，因解除合同使一方遭受損失的，除依法可以免除責任的外，應由責任方負責賠償。變更或解除合同的通知或協議必須采取書面形式，協議未達成之前，原合同仍然有效。

第三十六條監理方在應當獲得監理報酬之日起7天內仍未收到支付票據，委托方又未對監理方提出任何書面解釋時，或根據第三十四條及第三十五條已暫停執行監理業務時限超過一個月的，監理方可向委托方發出終止合同的通知，發出通知后7日內仍未得到委托方答復，可進一步發出終止合同的通知，如果第二份通知發出后，三個工作日內仍未得到委托方答復，可單方面終止合同或自行暫停或繼續暫停執行全部或部分監理業務。委托方承擔全部違約責任。

第三十七條 監理方由于非自己的原因而暫停或終止執行監理業務，其善后工作以及恢復執行監理業務的工作，應當視為額外工作，有權得到額外的報酬（可參考三十二條）。

第三十八條 當委托方認為監理方無正當理由而又未履行監理義務時，可向監理方發出指明其未履行義務的書面通知。若委托方發出通知后7日內沒有收到答復，可在第一個通知發出后10日內發出終止委托監理合同的通知，合同即行終止。

違約責任

第三十九條 由監理方單方面的原因造成的違約責任，監理方承擔賠償責任（參考第二十五條和第二十七條），賠償的最高限額不超過該工程監理服務合同款的50%；由委托方單方面的原因造成的違約責任，由委托方承擔賠償責任（參考第三十條）。

監理報酬

第四十條 正常的監理工作、附加工作和額外工作的報酬，按照監理合同專用條件中第八條的方法計算，并按約定的時間和數額支付。

第四十一條 如果委托方在規定的支付期限內未支付監理報酬，自規定之日起，還向監理方支付滯納金。滯納金按如下方式計算：

滯納金=拖欠金額×支付期限最后一日銀行貨款利率×拖欠時間累計(滯納金按每天千分之5收取)

第四十二條 支付監理報酬所采取的貨幣幣種、匯率由合同專用條件約定。第四十三條 如果委托方對監理方提交的支付通知中報酬或部分報酬項目提出異議，應當在收到支付書面通知書24小時內向監理方發出表示異議的通知，但委托方不得拖延其他無異議報酬項目的支付。

其它

第四十四條 在監理業務范圍內，如需聘用專家咨詢或協助，由監理方聘用的，其費用由監理方承擔，由委托方聘用的，其費用由委托方承擔。

第四十五條 監理方在監理工作過程中提出的合理化建議，使委托方得到了經濟效益，委托方應按專用條件中的約定給予經濟獎勵。

第四十六條 監理方駐地監理機構及其職員不得接受監理工程項目施工承包方任何報酬或者經濟利益。監理方不得參與可能與合同規定的與委托方的利益相沖突的任何活動。

第四十七條 監理方在監理過程中，不得泄露委托方申明的秘密，監理方亦不得泄露設計方、承包方等提供并申明的秘密。

第四十八條 監理方對于由其編制的所有文件擁有版權，委托方僅有權為本工程使用和復制此類文件，不得將此類文件外傳至與本工程無關的機構或個人，否則監理方有權追究法律責任。

爭議的解決

第四十九條 任何一方因違反合同的規定而引起責任糾紛和損害賠償，雙方應當協商解決，如未能達成一致，可提交主管部門協調，如仍未能達成一致時，根據權力約定提交仲裁機關仲裁，或向人民法院起訴。

第三部分 信息系統工程監理專用條件

第一條 本合同使用的法律及監理依據：

(1)國家信息產業部、建設部的有關規范；

(2)《中華人民共和國技術合同法》；

(3)本合同生效后若出現國家有關法律、法規變化，本合同應根據國家有關法律、法規作相應調整。

第二條 監理機構：

總監理工程師

第三條 委托方應提供的工程資料及提供時間：

(1)設計文檔、招標文件、施工方投標文件、工程合同、現場資料（包括原始資料）等；

(2)委托方提供文件目錄，文件號，文件正本，保密資料注明密級；監理方代表簽收文件，確認簽收日期；工程完工后監理方交還以上資料，委托方代表簽收并確認交還日期。

第四條委托方應在回復期限內對監理方書面提交并要求作出決定的事宜作出書面答復，特殊情況下可先口頭或電話答復并即補書面答復。書面答復在送達監理方時生效，收受方應用書面回執確認。若超過約定期限監理單位服務方未收到委托方的決定意見，可理解為委托方對監理方的明確建議意見無異議，并將該建議意見視為委托方的決定。委托方對監理方書面提交的要求決策的文件的回復期限：

(1)一般文件5個工作日；

(2)緊急事項報告文件2個工作日

第四篇：信息工程監理合同范本

信息工程監理合同范本

(含兩種)語言文字時，漢語應為解釋和說明本合同的標準語言文字。

監理方義務

第一條監理方按合同約定派出監理工作需要的監理機構及監理人員，向委托方報送委派的總監理工程師及其監理機構主要成員名單、監理規劃，完成監理合同專用條件中約定的監理工程范圍內的監理業務。在履行合同義務期間，監理方應在所監理項目的實施過程中根據工程具體情況采取傍站、巡視、平行檢驗等監理形式，并按合同約定，定期向委托方報告監理工作。

第二條 監理方在履行本合同的義務期間，應認真、勤奮地工作，為委托方提供與其水平相適應的咨詢意見，公正維護各方面的合法權益。

第三條 監理方使用委托方提供的設施和物品屬委托方的財產。在監理工作完成或中止時，應將其設施和剩余的物品按合同約定的時間和方式移交給委托方。

第四條 在合同期內或合同終止后，未征得有關方同意，不得泄露與本工程、本合同業務有關的保密資料。

第五條 工程最終驗收結束后一個月內，整理與監理有關的資料并移交委托方。

委托方義務

第六條 委托方在與監理方簽定本合同后，開展監理業務之前應向監理方免費提供工程相關 資料.第七條 委托方應當負責工程建設的所有外部關系的協調，為監理工作提供規定的工作環境和外部條件。根據需要，如將部分或全部協調工作委托監理方承擔，則應在專用條件中明確委托的工作和相應的報酬。

第八條 委托方應當在雙方約定的時間免費向監理方提供與工程有關的監理工作所需要的工程資料。

第九條 委托方應當在專有條款約定的時間內就監理方書面提交并要求作出決定的一切事宜作出書面決定。

第十條 委托方應當授權一名熟悉工程情況、能在規定時間內作出決定的項目聯絡人(在專用條款中約定)，負責與監理方聯系。更換項目聯絡人，要提前三日通知監理方。本工程的項目聯絡人是：_______________________。

第十一條 委托方應當將授予監理方的監理權利，以及監理方主要成員職能分工、監理權限及時書面通知己選定的承包合同的承包方，并在與承包方簽訂的合同中予以明確。

第十二條 委托方應在不影響監理方開展監理工作的時間內提供如下資料：

(1)在本項工程中使用的工程材料設備如通訊及計算機網絡設備、應用軟件等生產廠家名錄;

(2)提供與本工程有關的協作單位、配合單位的名錄及聯系人和聯系方式;

(3)協助安排監理服務機構在監理服務過程中所需的自備的設備、物品的進場時間。第十六條 委托方應免費向監理方提供臨時辦公用房、通訊設施。

第十三條 根據情況需要，如果雙方約定，由委托方免費向監理方提供必要的配合人員，在監理合同專用條件中予以明確。

監理方權利

第十四條 監理方在委托方委托的工程范圍內，享有以下權利：

(1)對信息系統工程建設有關事項包括工程規模、設計標準、規劃設計、工程實施方案和使用功能要求，向委托方的建議權。

(2)用于工程實施的設計文件(包括由集成承建單位提供的設計)的核查確認權，只有經監理服務機構確認并加蓋公章的設計文件才成為有效的工程建設依據;對工程設計中的技術問題，按照安全和優化的原則，向設計方提出建議;如果擬提出的建議可能會提高工程造價，或延長工期，應當事先征得委托方的同意。當發現工程設計不符合國家頒布的信息系統工程質量標準或設計合同約定的質量標準時，監理方應當書面報告委托方并要求設計方更正。

(3)審批工程施工組織設計和技術方案，按照保質量、保工期和降低成本的原則，向承包方提出建議，并向委托方提出《書面報告》。

(4)主持工程建設有關協作單位的組織協調，重要協調事項應當事先向委托方發出書面通知，協調結果向委托方提交《書面報告》。

(5)征得委托方同意，監理方有權發布開工令、停工令、返工令、復工令，但應當事先向委托方進行書面通知。如在緊急情況下未能事先通知時，則應在24 小時內向委托方作出《書面報告》。

(6)工作中使用的硬件、軟件及系統集成、材料和施工質量的檢驗權，向承包方獲取上述相關內容的質量證明文件的權利。對于不符合設計要求和合同約定及國家質量標準的材料、構配件、設備，有權通知承包方停止使用;對于不符合規范和質量標準的工序、分部分項工程和不安全施工作業，有權通知承包方停工整改、返工。承包方得到監理機構復工令后才能復工。

(7)工程施工進度的檢查、監督權，以及工程實際竣工日期提前或超過工程施工合同規定的竣工期限的簽認權。主持工程驗收及出具驗收報告的監理證明文件的權力。

(8)在工程施工合同約定的工程范圍內，行使工程量計量和工程款支付的審核和簽認權，以及工程結算的復核確認權與否決權。未經監理方簽字確認，委托方不得向承包方支付工程款，不進行竣工驗收。

第十五條監理方在委托方授權范圍內，行使工程變更審核權，確認其必要性后，由總監理工程師發布變更指令方能生效予以實施。如果由此嚴重影響了工程費用或質量或進度，則這種變更須經委托方事先批準。在緊急情況下未能事先報委托方批準時，監理方所做的變更也應盡快通知委托方。在監理過程中如發現工程承包方人員工作不力，監理機構可要求承包方調換有關人員。第二十條在所委托的工程范圍內，委托方或承包方對對方的任何意見和要求(包括索賠要求)，均必須首先向監理機構提出，由監理機構研究處置意見，再同雙方協商確定。當委托方和承包方發生爭議時，監理機構應根據自己的職能，以獨立的身份判斷，公正地進行調解。當雙方的爭議由政府行政主管部門調解或仲裁機關時，應當提供作證的事實材料。

委托方權利

第二十一條 委托方有選定工程總承包方、工程設計單位和系統集成商以及與其訂立合同的權利。

第二十二條 委托方有對工程規模、設計標準、規劃設計、生產工藝設計和設計使用功能要求的認定權，以及對工程設計變更的審批權。

第二十三條 當監理方調換總監理工程師時，須經委托方同意。

第二十四條 委托方有權要求監理方提交監理工作月報及監理業務范圍內的專項報告。

第二十五條 當委托方發現監理人員不按監理合同履行監理職責，或與承包方串通給委托方或工程造成損失的，委托方有權要求監理方更換監理人員，直到終止合同并要求監理方承擔相應的賠償責任或連帶賠償責任。

監理方責任

第二十六條 監理方的責任期即委托監理合同有效期。在監理過程中，如果因工程建設進度的推遲或延誤而超過書面約定的日期，雙方應進一步商議并簽署一份補充協議，作為本合同的附件，補充協議中應明確工程超期部分附加工作的監理附加費。

第二十七條 監理方在責任期內，應當履行約定的義務。如果因監理方過失而造成了委托方的經濟損失，應當向委托方賠償，按第三部分第六條計算，累計賠償總額不應超過該工程監理服務合同款的50%。

第二十八條 監理方有責任對承包方違反合同規定的施工質量及施工時限向委托方提交證明報告，但不因承包方的違規操作而承擔責任。因不可抗力導致委托監理合同不能全部或部分履行，監理方不承擔責任，但有責任維護委托方的權益，保證工程按質按量完成。

第二十九條 監理方向委托方提出賠償要求不能成立時，監理方應當補償由于該索賠所導致委托方的各種費用支出。

委托方責任

第三十條 委托方應當履行委托監理合同約定的義務，如有違反則應當承擔違約責任，賠償損失。

第五篇：《軟件工程》理論教學大綱

《軟件工程》理論教學大綱

(2000年制訂，2004年修訂)

課程編號：210024 英 文 名：Software Engineering 課程類別：專業主干課

前 置 課：計算機導論、程序設計基礎、數據結構、面向對象程序設計、離散數學 后 置 課：畢業設計和畢業論文 學

分：3學分

課

時：48課時（其中理論教學32課時，實驗教學16課時）主講教師: 韓忠愿等

選定教材: 張海藩.軟件工程.北京：人民郵電出版社.2002年.課程概述：

本課程面向信息系統與信息管理專業的學生，介紹軟件系統性質、目標、環境的分析方法，目標系統邏輯聯系、功能聯系、控制聯系和狀態轉換過程的描述方法，軟件結構、測試方案的設計要求和分析方法，軟件工程學新進展，以及上述過程所用的規范化圖文數表模型。具體包括：軟件工程概念及其過程模型、結構化分析/設計/實現方法和工具，面向對象方法學及面向對象的概念、模型、分析方法、設計方法、實現方法，軟件項目管理及其定量度量方法、相關國際標準。最后介紹佩特網等形式化方法、統一建模語言、軟件常用技術和軟構件的分類與檢索。教學目的：

本課程的教學目的，應使學生掌握大型復雜軟件系統的開發方法、規則和工具。首先，應使其克服長期書寫小程序形成的“重編碼、輕分析設計；重編碼、輕技術資料建設和管理”的習慣；其次，要理解軟件工程原理/方法/規則的必要性和掌握其技術細節；第三，要了解軟件工程學的進展和前沿動態；第四，要通過軟件系統設計的練習，鞏固和應用所學知識。教學方法：

本課程的難點在于，學生不曾經過大型軟件開發的訓練，因此在講解中要適時插入大量軟件開發事例，要求教師具有一定的軟件開發經驗；本課程不安排具體編程環境和開發語言的學習，但必須以大型軟件開發實例說明問題，因此要求教師熟悉多種開發環境和開發語言；此外，軟件開發技術的滯后和軟件應用的廣泛性所形成的反差，要求教師了解并適時提出計算機輔助軟件工程(CASE)的問題。因此，作為教師，應把案例的收集和規律的提取作為重點；作為學生，重點是掌握基本思想和基本方法及其綜合應用。教學中以講授和討論為主，實驗內容則是在Power Designer、Project、IBM Rational Rose等CASE環境下實習理論教學中的建模、分析和管理過程。各章教學要求及教學要點

第一章 軟件工程概述

課時分配：2課時 教學要求：

本章對計算機軟件工程學進行簡短的概述。首先要通過回顧計算機系統軟硬件關系的發展簡史，說明開發軟件的一些錯誤方法和觀念是怎樣形成的。然后列舉這些錯誤方法帶來的嚴重弊病(軟件危機)，澄清一些糊涂觀念。為了計算機系統的進一步發展，需要認真研究開發和維護軟件的科學技術。應總結計算機軟件技術發展的歷史經驗教訓，借鑒其他工程領域的管理技術。教學內容：

第一節

軟件工程

一、什么是軟件工程

概括地說，軟件工程是指導計算機軟件開發和維護的工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它，這就是軟件工程。

二、軟件工程的基本原理

1．用分階段的生命周期計劃嚴格管理； 2．堅持進行階段評審； 3．實行嚴格的產品控制； 4．采用現代程序設計技術； 5．結果應能清楚地審查； 6．開發小組的人員應該少而精；

7．承認不斷改進軟件工程實踐的必要性。

第二節 軟件工程方法學

一、方法學(methodology)范型(paradigm)瀑布模型、噴泉模型、快速原型模型、增量模型、螺旋模型。

二、軟件工程方法學三要素：方法、工具和過程。

三、傳統方法學和面向對象方法學 思考題：

1.什么是軟件工程？怎么應用軟件工程消除軟件危機？ 2.軟件工程化的觀點認為，軟件生命周期包含哪些階段？

3.簡要論述結構化范式和面向對象范式的要點，并比較這兩種范式的優缺點。

第二章 軟件過程

課時分配：2課時 教學要求：

本章需要明確：軟件過程是為了獲得高質量軟件產品所需要完成的一系列任務的框架，它規定了完成各項任務的工作步驟。軟件過程必須科學、合理，才能開發出高質量的軟件產品。按照在軟件生命周期全過程中應完成任務的性質，在概念上可以把軟件生命周期劃分成問題定義、可行性研究、需求分析、概要設計、詳細設計、編碼和單元測試、綜合測試以及維護等八個階段。實際從事軟件開發工作時，軟件規模、種類、開發環境及使用的技術方法等因素，都影響階段的劃分。因此，一個科學、有效的軟件過程應該定義一組適合于所承擔的項目特點的任務集合。據此，本章講授五類典型的軟件生命周期模型及其特點。教學要點

第一節 軟件生命周期的基本任務

一、問題定義—“要解決的問題是什么？”

二、可行性研究—“上一個階段所確定的問題是否有行得通的解決辦法？”

三、需求分析—用規格說明(specification)定義“目標系統必須做什么？”

四、概要設計—“怎樣實現目標系統?”

五、詳細設計—“怎樣具體地實現這個系統？”

六、編碼和單元測試—寫出正確的容易理解、容易維護的程序模塊。

七、綜合測試—通過各種類型的測試及相應的調試，使軟件達到預定的要求。

八、軟件維護—通過各種必要的維護活動使系統持久地滿足用戶的需要(改正性維護、適應性維護、完善性維護、預防性維護)。

第二節 瀑布模型

一、階段間具有順序性和依賴性。

二、推遲實現的觀點。

三、質量保證的觀點。思考題：

1.什么是軟件過程？它與軟件工程方法學有什么關系？

2.假設你要開發一個軟件，它的功能是把某個數開平方，所得的結果應該精確到小數點后4位。一旦實現并測試完畢后，該產品將會被拋棄。你打算選用哪種軟件生命周期模型？

3.列出上一題所述軟件產品在開發過程中可能遇到的風險。

第三章 結構化分析

課時分配：3課時 教學要求：

本章講授用戶需求的發現、求精、建模、規格說明和復審的過程。本章還要說明模型的以下作用：1.模型能幫助分析員更好地理解軟件系統的信息、功能和行為，從而使得需求分析工作更容易完成，使需求分析的結果更系統化。2.模型是復審需求分析成果時的焦點，因此，也成為驗證規格說明的完整性、一致性和準確性的重要依據。3.模型是設計的基礎，為設計者提供軟件的實質性表示，通過設計工作將把這些表示轉化成軟件實現。在此基礎上，引導學生使用實體—關系圖來建立數據模型，掌握數據流圖的基本符號，并能正確地使用這些符號建立目標系統的功能模型。此外，簡要說明狀態轉換圖和數據字典。教學內容：

第一節

概述

一、需求分析的含義（發現、求精、建模、規格說明和復審的過程）。

二、模型—為了理解事物而對事物做出的一種抽象，是對事物的一種無歧義的書面描述。

三、結構化分析通常建立數據模型、功能模型和行為模型等三種模型。

四、用分析模型表示軟件需求并寫出準確的軟件需求規格說明。

第二節 需求分析與需求工程

一、訪談—訪談(或稱為會談)。

最早開始運用的獲取用戶需求的技術，也是迄今為止仍然廣泛使用的主要的需求分析技術。

二、規格說明技術。

這種方法提倡用戶與開發者密切合作，共同標識問題，提出解決方案的要素，商討不同的方法并指定基本的需求。

三、軟件原型化方法。

構建原型的要點是，它應該實現用戶看得見的功能(例如屏幕顯示或打印報表)，省略目標系統的“隱含”功能(例如修改文件)。

第三節 軟件需求規格說明

一、軟件需求規格說明簡略大綱。

引言、信息描述、功能描述、行為描述、確認標準、參考書目、附錄。

二、需求規格說明書各部分的撰寫要點。

第四節 實體—關系圖

數據模型包含三種相互關聯的信息：數據對象、描述數據對象的屬性及數據對象彼此間相互連接的關系。

第五節 數據流圖

一、數據流圖符號。正方形(或立方體)表示數據的源點或終點；圓角矩形(或圓形)代表變換數據的處理；開口矩形(或兩條平行橫線)代表數據存儲；箭頭表示數據流，即特定數據的流動方向。

二、例子。

三、圖元命名。

第六節 狀態轉換圖

一、狀況轉換圖的各種圖形結構要素。

二、換圖的應用實例。

第七節 數據字典

一、數據字典是為了描述在結構化分析過程中定義的對象的內容而使用的一種半形式化的工具。

二、數據字典是所有與系統相關的數據元素的有組織的列表。

三、數據字典是對系統中使用的所有數據元素的定義的集合。

四、數據字典的內容（名字、別名、使用地點與方式、內容描述、補充信息）。

五、數據字典中表示數據構成的符號。思考題：

1.銀行計算機儲蓄系統的工作過程大致如下：儲戶填寫存款單和取款單，由業務員鍵入系統。如果是存款，則系統記錄存款人姓名、住址（或電話號碼）、身份證號、存儲類型、存款日期、到期日起、利率及密碼等信息，并打印存款單給儲戶；如果是取款而且存款時留有密碼，則系統首先核對儲戶密碼，若密碼正確和存款時未留密碼，則計算利息并打印利息清單。

2.用數據流圖描繪本系統的功能，并用實體聯系圖描繪系統中的數據對象。

第四章 結構化設計

課時分配：6課時 教學要求：

本章應使學生學會用各種圖形描繪軟件結構。描述程序處理過程的工具，可分為圖形、表格和語言三類，這三類工具各有所長，教學中應該讓學生能夠根據需要選用適當的工具。教學內容：

第一節

結構化設計與結構化分析的關系

結構化分析的結果為結構化設計提供了最基本的輸入信息，結構化設計是結構化分析的繼續。

第二節 軟件設計的概念和原理

一、模塊化。模塊是由邊界元素限定的相鄰的程序元素(例如，數據說明，可執行的語句)的序列，而且有一個總體標識符來代表它。像Pascal或Ada這樣的塊結構語言中的Begin?end對，或者C，C++和Java語言中的｛?｝對，都是邊界元素的例子。因此，過程、函數、子程序和宏等，都可作為模塊。面向對象范型中的對象是模塊，對象內的方法也是模塊。模塊是構成程序的基本構件。

模塊化就是把程序劃分成獨立命名且可獨立訪問的模塊，每個模塊完成一個子功能，把這些模塊集成起來構成一個整體，可以完成指定的功能滿足用戶的需求。

1.模塊可分解性； 2.模塊可組裝性； 3.模塊可理解性； 4.模塊連續性； 5.模塊保護性。

二、抽象。

三、逐步求精。

四、信息隱藏。

第三節 模塊獨立

一、耦合。

耦合是對一個軟件結構內不同模塊之間互連程度的度量，分為數據耦合，控制耦合，公共環境耦合，內容耦合。

二、內聚。

內聚標志一個模塊內各個元素彼此結合的緊密程度，它是信息隱蔽和局部化概念的自然擴展。分為功能內聚、順序內聚、通訊內聚、過程內聚、時間內聚、邏輯內聚、偶爾內聚。

第四節 啟發規則

一、改進軟件結構提高模塊獨立性。

二、模塊規模應該適中。

三、深度、寬度、扇出和扇入都應適當。

四、模塊的作用域應該在控制域之內。

五、力爭降低模塊接口的復雜程度。

六、設計單入口單出口的模塊。

七、模塊功能應該可以預測。

第五節 表示軟件結構的圖形工具

一、層次圖。

二、HIPO圖。

三、層次圖和HIPO圖的區別和所適用的情況。

第六節 面向數據流的設計方法

一、概念。

1.變換流—如果數據流圖中的輸入經過加工處理后才沿輸出通道變換成外部形式后離開軟件系統，這種數據流稱為變換流。

2.事務流—如果數據流圖中的輸入未經加工處理后就沿多個輸出通道離開軟件系統進入下一個分支，這種數據流稱為變換流。

二、變換分析。

復查基本系統模型、復查并精化數據流圖、確定數據流圖具有變換特性還是事務特性、確定輸入流和輸出流的邊界，從而孤立出變換中心、完成“第一級分解”、完成“第二級分解”、使用設計度量和啟發規則對第一次分割得到的軟件結構進一步精化。

三、事務分析。

事務分析的設計步驟和變換分析的設計步驟大部分相同或類似，主要差別僅在于由數據流圖到軟件結構的映射方法不同。

四、設計優化。

第七節 過程設計

一、經典的結構程序設計。

只允許使用順序、IF-THEN-ELSE型分支和DO-WHILE型循環這三種基本控制結構。

二、擴展的結構程序設計。

除了上述三種基本控制結構之外，還允許使用DO-CASE型多分支結構和DO-UNTIL型循環結構。

三、修正的結構程序設計。

在上述結構的基礎上，再加上允許使用LEAVE(或BREAK)的結構。

第八節 過程設計的工具

描述程序處理過程的工具稱為過程設計的工具，它們可以分為圖形、表格和語言三類。

一、程序流程圖。

二、盒圖(N-S圖)。

盒圖沒有箭頭，因此不允許隨意轉移控制。堅持使用盒圖作為詳細設計的工具，可以使程序員逐步養成用結構化的方式思考問題和解決問題的習慣。

三、PAD圖。

用二維樹形結構的圖來表示程序的控制流，將這種圖翻譯成程序代碼比較容易。

四、判定表。

當算法中包含多重嵌套的條件選擇時，判定表能夠清晰地表示復雜的條件組合與應做的動作之間的對應關系。

五、判定樹。

判定表雖然能清晰地表示復雜的條件組合與應做的動作之間的對應關系，但其含義卻不是一眼就能看出來的，初次接觸這種工具的人要理解它需要有一個簡短的學習過程。判定樹是判定表的變種，也能清晰地表示復雜的條件組合與應做的動作之間的對應關系。

六、過程設計語言(PDL)。思考題：

1.分析模型中的哪些信息為數據設計奠定了基礎？哪些信息為軟件體系結構設計奠定了基礎？那些信息為接口設計奠定了基礎？那些信息為過程設計奠定了基礎？

2.為每種類型的模塊偶合舉一個具體例子。3.對每種類型的模塊內聚舉一個具體例子。4.舉例說明信息隱藏和模塊獨立的關系。5.舉例說明藕合和可移植性的關系。

第五章 結構化實現

課時分配：3課時 教學要求：

學習本章后，為了設計出有效的測試方案，學生必須深入理解并應用指導軟件測試的基本準則，應該能夠應用各種測試方法設計軟件系統的測試方案，并根據測試結構進行錯誤定位、軟件調試和軟件可靠性估計等后續工作。教學內容：

第一節 軟件實現的基本問題

一、選擇程序設計語言。

二、編碼風格。

程序內部的文檔、數據說明、語句構造、輸入/輸出、效率。

第二節 軟件測試基礎

一、測試目標。

1.測試是為了發現程序中的錯誤而執行程序的過程；

2.好的測試方案是極可能發現迄今為止尚未發現的錯誤的測試方案； 3.成功的測試是發現了至今為止尚未發現的錯誤的測試。

二、黑盒測試和白盒測試。

三、測試準則。

1.所有的測試都應該能追溯到用戶需求；

2.應該在測試開始之前的相當長時間，就制定出測試計劃； 3.測試發現的錯誤中的80%很可能是由程序中20%的模塊造成的； 4.測試應該從“小規模”開始，并逐步進行“大規模”測試； 5.窮舉測試是不可能的；

6.為了達到最佳的測試效果，應該由獨立的第三方來從事測試工作。

四、流圖。

第三節 邏輯覆蓋

一、語句覆蓋。

二、判定覆蓋。

三、條件覆蓋。

四、判定/條件覆蓋。

五、條件組合覆蓋。

第四節 控制結構測試

一、基本路徑測試。

1.根據過程設計結果畫出相應的流圖； 2.計算流圖的環形復雜度； 3.確定線性獨立路徑的基本集合；

4.設計可強制執行基本集合中每條路徑的測試用例。

二、條件測試。

三、數據流測試。

四、循環測試。1.簡單循環； 2.嵌套循環； 3.串接循環。

第五節 黑盒測試技術

一、等價劃分。

1.如果規定了輸入值的范圍，則可劃分出一個有效的等價類輸入值在此范圍內（兩個無效的等價類輸入值小于最小值或大于最大值)。2.如果規定了輸入數據的個數，則類似地也可以劃分出一個有效的等價類和兩個無效的等價類。

3.如果規定了輸入數據的一組值，則每個允許的輸入值是一個有效的等價類，此外還有一個無效的等價類(任一個不允許的輸入值)。

4.如果規定了輸入數據必須遵循的規則，則可以劃分出一個有效的等價類(符合規則)和若干個無效的等價類(從各種不同角度違反規則)。

5.如果規定了輸入數據為整型，則可以劃分出正整數、零和負整數等三個有效類。6.如果程序的處理對象是表格，則應該使用空表，以及含一項或多項的表。

二、邊界值分析。

三、錯誤推測。

第六節 測試策略

一、測試步驟。

二、單元測試。1.代碼審查； 2.軟件測試。

三、集成測試。1.自頂向下集成； 2.自底向上集成； 3.回歸測試；

4.不同集成測試策略的比較。

四、確認測試。

第七節 調試

一、調試過程。

二、調試途徑。1.蠻干法； 2.回溯法； 3.原因排除法。思考題：

航空公司向軟件公司訂購了一個規劃飛行路線的程序。假設你是另一軟件公司的軟件工程師。航空公司已雇用你在的公司對上述程序進行驗收測試。你的任務是，根據下述事實設計驗收測試的輸入數據，并解釋你選取這些數據的理由：領航員向程序輸入出發點和目的地，以及根據天氣和飛機型號而初步確定的飛行高度。程序讀入途中的風向風力等數據，并且制定出三套飛行計劃（高度、速度、方向及途中的五個位子校核點）。所制定的飛行計劃應做到燃油消耗和飛行時間都最少。

第六章 面向對象的概念與模型

課時分配：3課時 教學要求：

面向對象方法學比較自然地模擬了人類認識客觀世界的思維方式，本章教學應使學生了解面向對象方法的概念和規律和工具，能夠用面向對象的思想描述問題域，從而建立關于軟件系統的對象模型，當然，出于面向對象建模的需要，也要重溫過程建模和功能建模方法。教學內容：

第一節

概述

一、面相對象思想基本內涵：OO=Objects+ Classes+ Inheritance+ Communication with messages。

二、面向對象方法學的主要優點。

與人類習慣的思維方法一致、穩定性好、可重用性好、較易開發大型軟件產品、可維護性好。

三、面向對象方法的其他概念。

(類Class)、對象、消息(Message)、方法(Method)、屬性(Attribute)、封裝(Encapsulation)、繼承(Inheritance)、多態性(Polymorphism)、重載(Overloading)。

第二節 對象模型

一、表示類—&—對象的圖形符號。

二、表示結構的圖形符號。

三、對象模型之例。

第三節 動態模型

一、概念。

二、符號。

第四節 功能模型

一、表示方法。二、三種模型之間的關系。思考題：

1.試分析傳統的生命周期方法學的優缺點。2.什么是面向對象方法學？這種方法有什么優點？ 3.什么是對象？它與傳統的數據有何關系？有何不同？ 4.什么是模型？開發軟件為什么要建立模型？ 5.什么是對象模型？ 6.什么是動態模型？ 7.什么是功能模型?

第七章 面向對象分析

課時分配：2課時 教學要求：

本章介紹面向對象思想和方法在具體軟件系統分析中的應用，包括一些具體的操作技術，如對象、屬性、聯系和行為的初選和求精等。本章講述的自動取款機系統和電梯系統這兩個實例，應該有助于讀者更深入、具體地理解面向對象分析的方法與過程。教學內容：

第一節 分析過程

一、概述。二、三個子模型與五個層次。

第二節 需求陳述

一、書寫要點。

二、例子。

第三節 建立對象模型

一、確定類—&—對象。1.找出候選的類—&—對象； 2.篩選出正確的類—&—對象。

二、確定關聯。1.初步確定關聯； 2.篩選； 3.進一步完善。

三、劃分主題。

四、確定屬性。1.分析； 2.選擇。

五、識別繼承關系。

六、反復修改。

第四節 其他過程

一、建立動態模型。

二、建立功能模型。

三、定義服務。

第五節 面向對象分析實例

思考題：

1.用面向對象方法分析研究一個儲蓄系統，試建立它的對象模型、動態模型和功能模型。2.用面向對象方法分析研究一個機票預定系統，試建立它的對象模型、動態模型和功能模型。

3.用面向對象方法分析研究一個患者監護系統，試建立它的對象模型、動態模型和功能模型。

第八章 面向對象設計

課時分配：2課時 教學要求：

本章在前面兩章關于面向對象思想及其基本應用的系統介紹的基礎上，考慮到面向對象分析與結構化分析在過程、要求和原則等方面的相似性，講授從略；同時考慮到具體實現技術的差異，著重介紹在面向對象方法中實現模塊化、信息隱蔽的若干技術。教學內容：

第一節 面相對象設計方法與過程

一、面向對象設計的準則。

二、啟發規則。

三、系統分解。

四、設計問題域子系統。

五、設計人-機交互子系統。

六、設計任務管理子系統。

七、設計數據管理子系統。

八、設計類中的服務。

九、設計關聯。

十、設計優化。

十一、面向對象分析與設計實例。

第九章 計劃

課時分配：4課時 教學要求：

軟件工程包括技術和管理兩方面的內容，是管理與技術緊密結合的產物。只有在科學而嚴格的管理之下，先進的技術方法和優秀的軟件工具才能真正發揮出它們的威力。因此，本章教學應使學生在認識軟件管理特點的基礎上，掌握主流的估算和評價指標，并能據此安排和優化軟件項目的進度。教學內容：

第一節 度量軟件規模

一、代碼行技術。

二、功能點技術。

功能點技術依據對軟件信息域特性和軟件復雜性的評估結果，估算軟件規模。1.信息域特性—輸入項數(Inp)、輸出項數(Out)、查詢數(Inq)，主文件數(Maf)和外部接口數(Inf)。

2.計算未調整的功能點數UFP。3.計算技術復雜性因子TCF。

第二節 工作量估算

一、靜態單變量模型：E=A+B×(ev)C。

二、動態多變量模型：E=〔LOC×B0.333/P〕3×(1/t)4。

三、COCOMO模型。

第三節 進度計劃

一、基本原則。

二、Gantt圖。

三、工程網絡。

四、估算進度。

五、關鍵路徑。

六、機動時間。思考題：

分析研究一個倉庫管理信息系統，要求： 1.用代碼行技術估算本系統的規模； 2.用功能點技術估算本系統的規模； 3.用靜態單變量模型估算開發本系統所需的工作量； 4.假設由一個人開發本系統，請制定進度計劃； 5.假設由兩個人開發本系統，請制訂進度計劃。

第十章 軟件工程項目管理組織

課時分配：2課時 教學要求：

本章教學要具體介紹國外比較流行的民主制程序員組、主程序員組和現代程序員組的組織方式，討論不同組織方式的優缺點和適用范圍。然后再從更廣闊的角度進一步討論通用的軟件項目組的組織結構問題，主要講述風險管理、質量保證和配置管理等三類軟件工程控制活動。教學內容：

第一節 組織策略

一、民主制程序員組；

二、主程序員組；

三、現代程序員組；

四、軟件項目組。

第二節 控制策略

一、風險管理；

二、質量保證；

三、配置管理。

第十一章 國際標準

課時分配：3課時 教學要求：

本章簡要地介紹幾個與軟件項目管理有關的國際標準，供學生在實際工作中參考、借鑒。教學內容：

第一節 常用標準

一、IEEE1058.1軟件項目管理計劃標準。

二、ISO9000質量標準。

三、ISO/IEC12207軟件生命周期過程標準。

四、ISO/IECTR15504軟件過程評估標準。

五、能力成熟度模型。

附 錄：參考書目

1.齊治昌等.軟件工程[M].北京：高等教育出版社，北京.1997.2.王選.軟件設計方法[M].北京：清華大學出版社，1992.3.Pont M J.Software Engineering with C++ and CASE Tools[M].Addison-Wesle，1996.4.周之英.現代軟件工程[M].北京：科學出版社，1999.5.張海藩.軟件工程導論(第三版)[M].北京：清華大學出版社，1998.6.張海藩.牟永敏.面向對象程序設計實用教程[M].北京：清華大學出版社，2001.7.張海藩等.計算機第四代語言[M].北京：電子工業出版社，1996.8.蔣慧等.UML設計核心技術[M].北京：希望電子出版社，2001.9.柏路等譯.C++面向對象的程序開發技術[M].北京：電子工業出版社，1996.10.Roger S.Pressman.Software Engineering—A Practitioner’s Approach.Fourth Edition[M].McGraw-Hill，1997.11.Stephen R.Schach.Software Engineering with Java[M].McGraw-Hill，1999.執筆人：

韓忠愿

審定人：

程國達

2004年6月

2004年6月

2004年6月

院(系、部)負責人：韓忠愿