10.3案例三:網絡應用系統
閱讀以下關于信息系統項目管理過程中綜合性問題的敘述,回答問題1至問題4。
10.3.1案例場景
某地區政府部門建設一個面向綜合性網絡應用系統,對現有的分布在各個服務器上的多個管理系統和服務平臺進行重組和整合,整個項目由政府的信息部門負責統一規劃、分期建設,由各個共建單位的主要領導組成了領導小組,招標選擇了某IT技術公司負責承建該應用系統。
項目采用整體規劃、分步實施的方式進行,第一期重點建設了社保、協同辦公和民政三個應用系統。建設過程中由于機構改革、職能需要重新定位等原因,《需求規格說明書》始終找不到最終用戶簽字,在項目經理的一再努力下,
只有一個共建單位的主管領導在該項目的需求分析上簽字確認,為了趕進度該公司項目經理決定先行設計和實施。
在實施中,項目經理制定了如圖10-1所示的單元測試進度計劃,圖10-1中已標出每個節點的最早開始時間和最遲開始時間。監理工程師在第5天進行檢查時,發現工作A已經完成,工作B已經實施3天,工作C已經實施了1天,工作D已經實施1天。
工程竣工驗收時,項目經理向建設單位提交了驗收申請,并將竣工驗收所需要的全部資料報送建設單位的項目經理,隨即向項目監理方的總監理工程師項目申請竣工驗收的報告。監理方總監理工程師認為系統已經過初驗和3個月的試運行,并且運行情況良好,隨即對驗收申請報告予以簽認,并進行后續的驗收工作。
【問題1】(6分)
根據案例的描述,請用400字以內的文字描述在本項目的建設前期出現的問題,該項目經理應該如何處理這些問題。
【問題2】(6分)
根據對單元測試進度檢查的結果,請確定:(1)工作B、C、D的進度是正常還是延誤(給出延誤的天數):是否影響工期并說明為什么。(2)在項目總工期允許拖延的情況下,請重新計算網絡時間參數并填入圖10-2的空(1)-(30)中。總工期是正常還是延誤?若延誤,請給出延誤天數。
【問題3】(8分)
請用200字以內的文字描述單元測試,以及項目團隊應該產生的單元測試工作成果。
【問題4】(8分)
請用400字以內的文字描述竣工驗收時,甲乙雙方的項目在執行驗收程序方面的做法正確嗎?如果正確,請說明理由;如果不正確,請說明正確的做法。
10.3.2案例分析
本案例描述了信息系統建設需求分析、單元測試、進度控制,以及項目驗收方面的工作。屬于一道綜合性考察的題目。
【問題1】
需求分析階段的工作成果是產生經過認可的《需求規格說明書》,需求分析大致可分成三步來完成。
(1)需求信息的收集。
(2)需求信息的分析整理,對收集到的信息要做分析整理工作。
(3)需求信息的評審。
開發過程中的每一個階段都要經過評審,確認任務是否全部完成,避免或糾正工作中出現的錯誤和疏漏。需求評審通過,產生規格說明書是需求分析階段結束的標志,‘評審可能導致需求分析過程回溯,甚至會反復多次。但是,一定要使全部的預期目標都達到,才能讓需求分析階段的工作暫告一個段落。
從客戶角度而言,識別需求是項目啟動過程和整個項目生命周期的最初活動,客戶通過識別商業或市場需求、機會、確定投資方向和項目機會,在這個過程中,將給項目的目標確定、可行性分析和項目立項提供直接、有效依據,為需求建議書的撰寫提供基礎。
從承建方的角度而言,識別需求是得到客戶的需求建議書,或只是得到客戶初步需求意向后,項目團隊從技術實現、應用和項目實施角度識別客戶的實際存在的問題、基本意圖和真實想法,從而達到與客戶有效的溝通,準確分析需求和問題,為制訂可行、合理、正確的技術及實施解決方案提供依據。
在軟件項目開始啟動的初期,用戶會向開發方提交需求描述,內容包括:目標產品的工作環境描述及用戶對目標產品的初步展望,其目的僅在于向開發人員解釋其需求。
需求規格說明書與需求描述完全不同,它是由開發人員經需求分析后形成的軟件文檔,其內容更為系統、精確和全面。
在結束需求分析階段之前,必須形成《需求規格說明書》。
本題中,項目需求分析的成果并沒有經過評審,沒有得到用戶方的認可。
而作為用戶也沒有充分意識到《需求規格說明書》的重要性。因此,項目經理需要積極協調,讓甲乙雙方達成需求上的一致認識。
【問題2】
本題涉及到時間管理中的網絡圖。首先根據題目的意思可以計算出表10-2中所示的數據。
根據表10-2中數據的計算,可以計算出C工作延期2天,由于C工作的延期,隨機導致了后續的F工作的延期,因此(5)的最早開始時間產生變化,從而導致了(6), (7)的最早開始時間產生變化。
【問題3】
軟件測試是有計劃、有組織和有系統的軟件質量保證活動,而不是隨意、松散、雜亂地實施過程。為了規范軟件測試內容、方法和過程,在對軟件進行測試之前,必須創建軟件測試計劃。
軟件測試計劃是指導測試過程的綱領性文件,包含了產品概述、測試策略、測試方法、測試區域、測試配置、測試周期、測試資源、測試交流、風險分析等內容。借助軟件測試計劃,參與測試的項目成員,尤其是測試管理人員,可以明確測試任務和測試方法,保持測試實施過程的順暢溝通,跟蹤和控制測試進度,應對測試過程中的各種變更。
測試階段的劃分應該與開發階段劃分相對應,如需求分析相對應的是確認測試,與概要設計相對應的是集成測試,與詳細設計相對應的是單元測試。
單元測試也就是模塊測試。通常被放在編碼階段,由程序員完成這個模塊后對他自己寫的模塊內代碼進行測試,檢查它是否實現了詳細設計說明書中規定的模塊功能和算法。單元測試是驗證詳細設計(各個模塊)正確性的測試,通常由開發組成員的自測和交叉測試完成。一般的測試流程為:編寫軟件單元測試說明,執行軟件單元測試,編寫軟件單元測試報告。
除了單元測試,還有集成測試和確認測試。集成測試又稱組裝測試,是在開發環境下,驗證概要設計正確性的測試。集成測試按照測試計劃和用例,由測試組成員完成。確認測試是在運行環境下,由用戶參與驗證需求規格說明書的正確性的測試,主要測試軟件功能與用戶需求是否一致。
【問題4】
項目的驗收主要包括了項目質量和項目文件的驗收。不同的項目有不同的驗收方式,有的按生命周期分階段性驗收,有的按照整體交付成果進行一次驗收,有的按照項目驗收的范圍和特點制訂驗收方式。但不論哪種驗收方式,質量驗收和文件驗收都是項目驗收過程中必要的、不可分割的重要組成部分。
本題考核工程驗收方面的知識,考生要熟悉相關的驗收程序,如驗收的幾個前提條件,確認工程驗收的基本條件、驗收的程序等。在工程驗收的準備階段,應完成以下工作:
(1)督促承建方制訂驗收方案,整理竣工圖紙及相關資料。
(2)協同業主、設計單位進行技術資料整理。
(3)組織人員編寫竣工決算,起草工程驗收報告的各種文件和表格。
(4)初驗。
初驗是在承建方自檢的基礎上,由業主、承建方、監理方組成項目初驗小組,對工程各項工作進行全面檢查,合格后才提出正式的竣工驗收申請。
正式驗收前,竣工申請和竣工驗收報告均要經過評審,符合條件才可組織正式驗收,正式驗收的一般程序包括了8個步驟。本題中,竣工驗收申請沒有經過負責驗收的單位的評審,總監理工程師根本沒有權力在竣工驗收申請上簽字。
對于軟件項目的驗收,提交驗收的軟件項目必須具備以下的條件:
(1)已通過計算機軟件確認測試評審。
(2)已通過系統測試評審。
(3)合同或合同附件規定的各類文檔齊全。
(4)軟件產品已經置于配置管理之下。
(5)合同或合同附件規定的其他驗收條件。
對于信息網絡的驗收,必須符合以下幾個條件:
(1)所有建設項目按照批準設計方案要求全部建成,并滿足使用要求。
(2)各個分項工程全部初驗合格。
(3)各種技術文檔和驗收資料完備,符合集成合同的內容。
(4)系統建設和數據處理符合信息安全的要求。
(5)外購的操作系統、數據庫、中間件、應用軟件和開發工具符合知識產權相關政策法規的要求。
(6)各種設備經加電測試運行,狀態正常。
(7)經過用戶同意。
10.33參考答案
【問題1】(6分)
項目建設前期中最主要的問題是《需求規格說明書》沒有獲得用戶的認可就開始項目建設。如果剛開始的需求規格沒有定義清楚,或未達成一致,則最終交付產品或服務時將很容易發生糾紛,造成不必要的損失。
《需求規格說明書》是為了使用戶和軟件開發者雙方對該軟件的初始規定有一個共同的理解而編制成的說明書,是需求分析階段的成果,是整個開發工作的基礎。項目經理應該充分與建設方項目經理進行協調,讓甲乙雙方達成需求上的一致認識。只有當《需求規格說明書》被確認后才能繼續下一步的工作。其項目網絡圖如圖10-3所示。
【問題2】(6分)
工作C的進度延期2天,總工期延期2天。
【問題3】(8分)
單元測試也就是模塊測試。通常被放在編碼階段,由程序員完成這個模塊后對他自己寫的模塊內代碼進行測試,檢查它是否實規了詳細設計說明書中規定的模塊功能和算法。單元測試是驗證詳細設計(各個模塊)正確性的測試,通常由開發組成員的自測和交叉測試完成。一般的測試流程為:編寫軟件單元測試說明,設計測試用例,執行軟件單元測試,編寫軟件單元測試報告。
單元測試成果有《軟件單元測試說明》、《單元測試用例說明》、《軟件單元測試報告》等。
【問題4】(5分)
不正確。項目監理方無權對驗收申請予以簽認,也無權進行后續的驗收工作。應由上級主管部門或負責驗收的單位收到竣工驗收申請和竣工驗收報告后,經過評審、確認符合竣工驗收條件和標準,才可組織正式驗收。