前言:想要寫出一篇令人眼前一亮的文章嗎?我們特意為您整理了5篇測試報告缺陷分析范文,相信會為您的寫作帶來幫助,發現更多的寫作思路和靈感。
測試不是挑毛病
然而,對測試領域先行者Glenford Myers先生“測試的目的是證偽”這一概念理解也不能過于片面。在很多軟件工程學、軟件測試方面的書籍中都提到一個概念:“測試的目的是尋找錯誤,并且是盡最大可能找出最多的錯誤”。這很容易讓人們認為測試人員就是“挑毛病”的,而由此帶來諸多問題。
我們可以假想在一個軟件開發公司內,軟件測試人員專注于“挑毛病”,開發人員和公司管理層每天會得到這樣“簡潔”的測試報告:“在今天的測試過程中,系統出現10次宕機現象”。
從“挑毛病”的角度看,測試人員已經很好的完成了自己的工作,但其工作成果對開發人員和公司管理層幾乎沒有任何幫助。開發人員面對這樣的測試報告是無法對軟件進行任何修改的;而公司管理層也會疑惑軟件質量到底如何,系統能否如期。
長此以往,必然會造成開發人員和測試人員之間無法調和的矛盾;而公司管理層也會認為,測試團隊只是“帶來壞消息的人”,對公司產品沒有提供任何幫助,不如取消為好。
這樣的例子看似比較極端,業內普遍認為類似的問題僅出現在一個初創測試團隊的公司內,但實際的情況遠沒有這樣樂觀,這類現象甚至還蔓延到近年來蓬勃興起的部分第三方測試機構之中。
一個軟件開發公司的管理者,拿到一份剛由某第三方測試機構完成的測試報告,報告結論是該公司開發的軟件無法完成預定的需求,在500個用戶并發交易的情況下會發生大量交易失敗。應該說這樣的報告確實挑出了軟件的“毛病”,但報告中并未提及造成交易失敗的原因,是硬件資源不足、支撐軟件參數設置錯誤還是應用開發問題。這樣的報告會使得委托測試單位置疑自己投資進行第三方測試的是否有實際幫助。
造成這些問題的原因歸根結底就是對“測試的目的是證偽”這一概念的片面理解。那么,一次成功的測試是如何對問題進行闡述的呢?質量工程學中軟件失效的機理給出了很好的答案。
軟件錯誤是人為錯誤
質量工程學中對于軟件失效是這樣分析的:由于軟件內部邏輯復雜,運行環境動態變化,且不同的軟件差異可能很大,因而軟件失效機理可能有不同的表現形式。
譬如有的失效過程比較簡單,易于追蹤分析,而有的失效過程可能非常復雜,難于甚至不可能加以詳盡描述和分析,尤其是運行于高度復雜實時環境中的大型軟件。
但總的說來,軟件失效機理可描述為:軟件錯誤?軟件缺陷?軟件故障?軟件失效。如圖1所示,是軟件錯誤發生的過程。
軟件錯誤軟件錯誤是指在軟件生存期內的不希望或不可接受的人為錯誤,其結果是導致軟件缺陷的產生。可見軟件錯誤是一種人為過程,相對于軟件本身,是一種外部行為。
軟件缺陷軟件缺陷是存在于軟件(文檔、數據、程序)之中的那些不希望或不可接受的偏差,如少一逗點、多一語句等。其結果是軟件運行于某一特定條件時出現軟件故障,這時稱軟件缺陷被激活。
軟件故障軟件故障是指軟件運行過程中出現的一種不希望或不可接受的內部狀態。譬如軟件處于執行一個多余循環過程時,我們說軟件出現故障。此時若無適當措施(容錯)加以及時處理,便產生軟件失效。顯然,軟件故障是一種動態行為。
軟件失效軟件失效是指軟件運行時產生的一種不希望或不可接受的外部行為結果。
因此,軟件錯誤是一種人為錯誤。
逆流而上解決問題
我們了解了軟件失效的機理后,就可以逆流而上,沿著軟件失效噯砑故障噯砑缺陷噯砑錯誤的方向對問題進行闡述和分析?首先,測試人員會說明軟件出現了問題,在此對軟件失效現象進行了描述;
其次,測試人員會詳細闡明是在哪個測試用例的作用下(包括輸入數值、處理過程和預期輸出結果),軟件產生了何種異常輸出,問題的類型、嚴重程度、修改的緊急程度如何,這樣就明晰了軟件故障的情況;
第三,測試人員會根據測試經驗和實際情況,幫助開發人員進行故障定位,找到軟件缺陷所在;
第四,測試人員在對問題情況進行統計的基礎上,會指出共性問題并分析其產生的原因,發現軟件錯誤。
在這樣對問題進行充分分析的基礎上,對問題提出修改意見,這樣一份問題報告會是一份對開發人員和管理層有意義的報告。
我們可以按照這樣的分析方法,對前面企業內部和第三方的兩個測試失敗的情況進行修正。
軟件失效現象:發生宕機/不能承擔500個用戶的并發交易;軟件故障情況:在使用非法數據輸入的情況下發生宕機/在進行用戶交納月通話費的情況下交易失敗;軟件缺陷:軟件中缺少合法性校驗/服務器CPU占用率達到98%;軟件錯誤:詳細設計環節缺少合法性校驗內容,且文檔評審工作不到位/概要設計環節未進行關鍵技術驗證與仿真;修改建議:增加合法性校驗,加強文檔評審工作/重新選擇服務器(重點是CPU),加強對關鍵技術的驗證與仿真工作。
對于所有問題,都應該對軟件的失效現象和故障情況做清晰的表述。除了嚴重程度會影響外,人員差異也對問題分析的程度有著較大影響。不同的測試人員需要承擔不同的職責。
軟件測試需三方協調
通過上面的分析可以看到,軟件測試的目的決不僅僅是“尋找錯誤”,今天的軟件測試需要在三個方面和開發協調工作,其相互作用如圖2所示。
測試的目的是想以最少的人力、物力和時間找出軟件中潛在的各種錯誤和缺陷,通過修正種錯誤和缺陷提高軟件質量,回避軟件后由于潛在的軟件缺陷和錯誤造成的隱患帶來的商業風險。這一工作靠對軟件失效現象記錄、軟件故障表示、軟件缺陷的分析完成。
通過分析錯誤產生的原因還可以幫助發現當前開發工作所采用的軟件過程的缺陷,以便進行軟件過程改進;同時通過對測試結果的分析整理,還可以修正軟件開發規則,并為軟件可靠性分析提供依據。這一工作靠對軟件錯誤的分析完成。
1、需求分析:首先需要要學習并了解軟件的業務,分析需求點;
2、測試計劃:編寫整個測試計劃,在這個過程中需要參考需求規格說明書,這個階段一般情況下是測試主管編寫。包括了測試人員,測試時間,測試工具,測試方法等;
3、測試用例設計:是測試工作中的最核心的模塊,在執行任何測試之前,首先必須完成測試用例的編寫。測試用例是指導執行測試,幫助證明軟件功能或發現軟件缺陷的一種說明。用例設計好之后,會進行評審;
4、用例執行:搭建環境,準備好測試數據,進行預測,預測通過后,按照測試用例進入正式測試;
(1)結合實際確定合理的戰術技術指標、實現技術和工藝。結合實際確定合理的立項裝備戰術技術指標,在初步方案設計中盡量采用成熟的技術和工藝,慎重采用新材料、新技術和新工藝,不可盲目追求“高精尖”或“大而全”,已夠用好用作為方案設計的基本原則,兼顧系統改建、性能擴展和升級的需要。做好可靠性的預測和安全性、可靠性設計工作,通過設計更改想法,排除或減少設計方案中的危險因素。在經過重大更改后應對方案重新進行風險分析與評估。如果通過設計更改仍不能消除方案中的嚴重危險因素或降低其危險性,則應放棄當前的方案重新進行方案設計。
(2)建立科學嚴謹的項目立項程序。新裝備項目(包括所有裝備立項項目)立項應有一套科學嚴謹的程序,不能憑感性認識或經驗辦事。應成立由有關各方面專家組成的論證小組,對裝備研制的可行性、戰術技術指標的合理性、設計方案的符合性等從技術、進度、質量、風險各方面進行綜合論證和評價,選擇最佳方案。既要防止草率盲目地啟動研制工作,也要防止過分小心謹慎而耽誤了研制工作的及時展開,同時要杜絕個別人假借組織的名義進行個人決策。
(3)認真審查和選擇研制單位(或協作單位)。新裝備研制單位應該有高度的國防觀念和軍品意識、良好的運營環境、優秀的人才隊伍、完善有效的質量保證體系、優良的經營信譽。是否有過類似產品的研制經理、其結果如何也是可供參考的重要因素。
(4)簽訂科學、規范、完整的研制合同。新裝備研制合同應科學、規范、完整,明確各種技術、質量、進度等要求,力戒含糊不清、模棱兩可的敘述。研制合同既是研制過程中技術、經濟、質量管理的法律文件,也是進行新裝備管理的主要依據。簽訂合同時必須具有強烈的風險意識,學會從風險分析與風險管理的角度研究合同的每一個條款,對可能遇到的風險因素有全面深刻的了解。在合同中對各自的權利和義務做出明確規定,充分體現利益共享風險分擔的原則。為了實現上述目標,確保新裝備研制的質量,科研單位應該制定詳細的質量管理過程文件,經過評審后頒布執行,為質量管理體系有效運轉打好基礎。這一階段的質量管理過程文件主要包括立項裝備需求調研提綱、立項裝備需求調研報告、立項裝備建設方案、立項裝備建設方案評審報告、單位或上級年度科研項目計劃、研制任務書、質量保證計劃、風險評估報告、項目經費預算、研制任務書評審報告、評審所提問題及處理情況等。這些質量管理過程文件可以根據研制的新裝備的具體情況制定和取舍。
2總體方案設計階段質量管理過程文件
總體設計方案是整個裝備設計的龍頭,其設計質量將直接關系到未來裝備的性能。總體方案設計既要充分利用已有的成熟技術,縮短研制周期,又應有所創新,利用最新的科研成果提高裝備的技戰性能。由于總體設計方案的質量是確保裝備最終質量和裝備整體質量的源中之源、重中之重,放松不得,馬虎不得,因此,科研單位應制定詳細的這一階段的質量管理過程文件。這一階段的質量管理過程文件包括裝備技術調研提綱、裝備技術調研報告、裝備設計開發計劃、裝備總體技術方案、可靠性設計大綱、維修性設計大綱、保障性設計大綱、測試性設計大綱、安全性設計大綱、環境適應性設計大綱、環境分析報告、標準化大綱、總體技術方案評審報告、評審所提問題及處理情況等。經過評審后頒布執行,以確保總體方案設計的質量,從而最終確保研制的裝備整體質量。
3詳細設計及軟硬件開發階段質量管理過程文件
(1)嚴格控制新技術風險因素。為了確保新研制裝備的先進性,采用一些新技術、新器件、新材料是必需的,但是為了確保新研制裝備的綜合效能(性能優、壽命長、故障少、易維修、易保障、最佳費用比)和質量,在方案審查中,要嚴格控制新技術、新器件、新材料的采用比例,要對技術風險、制度風險、費用風險、后續保障風險和潛在的質量問題進行認真嚴格的把關;
(2)加強對改進型研制裝備的方案審查。要特別注重對成熟技術的借用,注重裝備使用質量物理模型的建立和選用,以及對改進技術的研究,要把評審后的改進意見落實到設計方案中;
(3)要注重裝備系統的接口技術和方案的審查,使裝備各分系統達到最佳組合。這一階段的質量管理過程文件包括:系統硬件設計方案、系統硬件設計方案評審報告、設備清單、外包合同采購計劃、設備器材驗收報告、系統硬件平臺測試評審報告、軟件需求規格說明書、需求分析評審報告、軟件概要設計說明、概要設計評審報告、軟件詳細設計說明、軟件詳細設計評審報告、軟件源代碼報告、軟件單元測試報告、軟件單元測試問題報告、軟件單元測試評審報告、軟件部件測試報告、軟件部件測試問題報告、軟件部件測試評審報告、軟件配置項測試報告、軟件配置項測試問題報告、軟件配置項測試評審報告、軟件系統測試大綱、軟件系統測試細則、軟件分系統測試報告、軟件分系統測試問題報告、軟件分系統測試評審報告、設計和開發問題及處理結果匯總表、評審所提問題及處理情況等。
4系統研制及集成階段質量管理過程文件
裝備研制是把設計方案變成藍圖,并把藍圖變成實物的過程,也是新型裝備從孕育到誕生的過程。研制的裝備是否能夠達到預期的戰術技術指標、產品質量是否滿足要求都取決于這個階段,該階段的風險控制工作對裝備研制的成敗起著決定性的作用,是裝備全壽命周期內風險防范與控制的重中之重。裝備研制階段的主要工作是根據研制合同或技術協議的要求,對購方的需求進行分析,確定其功能基線和詳細設計方案,進行裝備的詳細設計、樣件加工,以及進行鑒定試驗和定型工作。由于多種原因及條件的限制,許多在方案論證及產品預研階段未能徹底突破的關鍵技術及未能量化的技術要求都被帶到研制階段,使研制階段的技術風險增大。研制階段的工作任務繁重,面臨的風險因素眾多,是風險因素集中、高發的階段,技術風險、資金風險、進度風險、組織人才風險、政策風險與道德風險都會給研制工作帶來嚴重影響。在進行裝備設計時應注重安全性、可靠性、工藝性、測試性、維修性、保障性設計。設計失誤是最大的失誤,一點微小的疏忽都可能給生產、使用和保障帶來意想不到的困難甚至災難。在該階段控制好風險對于降低批生產和維護保障階段的風險有重要意義。要重視設計的工藝性,在研制過程中,應注重考察設計的工藝性(包括工裝設備、工藝流程、工藝規程等),特別是新設備、新工藝及特種工藝等,發現和消除工藝設計及工藝文件的缺陷,以滿足未來裝備批生產的需求。注重產品的鑒定(定性)試驗、可靠性試驗及使用環節。通過試驗及使用及時發現和處理產品的故障及設計缺陷,及時采取糾正、預防措施,并將其落實到設計更改中去。加強技術狀態的控制與管理。在研制階段,產品的技術狀態復雜多變,管理上的疏忽會引起產品技術狀態的混亂。要按國軍標的要求做好技術狀態的控制與管理。這一階段的質量管理過程文件包括用戶檢測大綱、系統測試報告、系統測試問題報告、用戶檢測評審報告、設計和開發問題及處理結果匯總表、評審所提問題及處理情況等。
5驗收與交付階段質量管理過程文件
現在許多試制裝備在科研、生產、驗收、交付和使用過程中是高度交叉的,科研與生產無論是技術狀態還是時間周期上已經沒有明顯的界線劃分,研制階段的風險因素會影響生產、驗收和交付,生產階段的風險因素會影響到裝備的使用和保障。要控制好驗收與交付階段的風險,保質保量完成裝備交付任務,需要加強生產組織管理、加強技術狀態控制、加強質量管理,應根據裝備產品技術規范的要求做好例行試驗和定期檢驗工作,認真分析和解決試驗中出現的各種問題,抓好問題的歸零處理和措施落實工作,完善履歷、技術說明書、操作規程、備品備件等相關資料。這一階段的質量管理過程文件包括驗收大綱、用戶驗收結果報告、用戶驗收評審報告、試運行記錄、試運行報告、設計定型報告、用戶驗收交接清單、顧客滿意度分析、數據分析等。
6結束語
摘 要:軟件維護在現實的軟件開發過程中占有十分重要的地位,本文介紹了我院的軟件維護實踐教學的教學方案以及具體實施情況。
關鍵詞:軟件工程;軟件開發;實驗;實踐教學;軟件維護
中圖分類號:G642
文獻標識碼:B
1 軟件維護在軟件工程實踐教學中的意義
軟件工程是一門理論與實踐并重的基礎課程,教學內容緊密圍繞軟件開發過程中的各種工程化方法、技術和思想[1]。在現實的軟件開發過程中,軟件維護占有很重要的地位,許多報告都指出軟件維護成本已經占到總體成本的40%~70%以上。軟件維護關注于“變化”,包括糾錯性(corrective)、適應性(adaptive)、完善性(perfective)、預防性(preventative)等維護類型[2]。當前的軟件工程教學中一般都已經包括了軟件維護相關理論和方法相關的內容,例如軟件維護及可維護性的概念、軟件維護的類型和過程、變更管理以及軟件再工程等。但軟件工程實踐教學仍然以瀑布式的正向開發過程為主,主要體現需求分析、設計、實現和測試等基本開發活動,缺少軟件維護的實踐訓練。
由于軟件維護在軟件開發中的重要性,許多國內外學者都呼吁在軟件工程教學中引入軟件維護實踐(如文獻[3])。在軟件工程實踐教學中引入軟件維護內容主要基于以下這些考慮。
首先,軟件維護在軟件開發中占有十分重要的地位,典型的軟件工程開發中花在軟件維護上的時間往往比軟件開發還要多[3]。而且,大部分畢業生進入軟件開發機構后都是從維護性的開發任務開始的。
其次,軟件維護實踐還能使學生更直觀地體會和理解軟件工程方法和原則的重要性。軟件工程教學中系統地講授了許多重要的軟件工程方法和原則,包括軟件文檔規范、設計原則(如層次化、高內聚低耦合等)以及編碼習慣(如標識符命名、注釋和排版等)等,其中大部分都與軟件的可維護性相關。通過對文檔不全、設計混亂和編碼習慣不好的軟件系統進行維護,可以對這些方法和原則獲得直觀、深入的認識和理解。例如,對標識符命名不規范、缺少注釋、排版混亂的代碼進行閱讀和理解,可以深刻認識到好的編碼習慣對于維護工作的重要性。
此外,軟件維護實踐能使學生更好地認識軟件開發的現實困難。缺陷報告、需求變更、軟硬件平臺的變化等導致軟件演化的因素在現實的軟件開發中總是存在的。通過在實踐教學中設置階段性的需求變更,可以讓學生對于現實的軟件開發有更加真實的體驗,從而提高對迭代、增量式開發等實用的軟件開發方法和技術的認知。
2 軟件維護實踐教學方案
軟件維護主要包括糾錯性、適應性、完善性和預防性維護四種類型[2]:糾錯性維護是針對所發現的錯誤或缺陷而對軟件進行的修改;適應性維護是為了適應外部環境(如硬件、操作系統、外部規則等)的變化而對軟件進行的修改;完善性維護是由于功能擴展而進行的軟件修改;預防性維護是面向未來的維護需要,為了提高軟件的適應性和可維護性等而進行的系統優化和改進。軟件維護實踐教學應以循序漸進的方式覆蓋這四個方面的軟件維護任務,同時穿插并突出相關軟件工程方法和原則的體驗和熏陶。
根據這一總體目標,相應的軟件維護實踐教學將在給定的作為維護對象的遺留系統基礎上,分三個階段進行,如圖1所示。遺留系統分析評估階段的主要目的是在理解遺留系統需求的基礎上對系統的外部和內部質量進行初步的了解和評價。系統改進維護階段的目標是以當前系統需求為基礎,對遺留系統的缺陷和錯誤進行修改,對系統內部的設計、實現以及文檔質量進行改進。系統需求演化維護階段通過若干次迭代的需求和系統環境變更,進行系統的完善性和適應性維護。針對新需求和系統環境設置的修改將通過系統測試確認,測試結果反饋給系統改進維護階段,從而進行相應的糾錯性維護活動。此外,系統修改過程中發現的內部質量問題(例如可擴展性上的不足等)同樣也會反饋給系統改進維護階段,從而進行相應的預防性維護活動。這種反饋關系以及需求和系統環境變更的迭代進行使得后兩個階段將反復迭代進行。
(1) 遺留系統分析評估階段
與傳統的基于分析、設計和實現的軟件工程實踐教學不同,軟件維護實踐教學以已經開發完成的遺留軟件系統作為起點。每個小組分配到的遺留系統都是由其他人開發的,猶如在軟件開發中接手其他小組的維護工作。因此,首先要求他們在理解項目當前需求的基礎上,對所分配的系統進行分析和評估,從而為后續的維護活動打下基礎。這階段的主要實踐任務包括:
圖1 軟件維護實踐教學過程
1) 理解遺留系統需求。與正向軟件開發一樣,軟件維護實踐也要從了解系統需求開始。需求是評價當前系統質量,進而規劃并實施各種糾錯性、適應性、完善性和預防性維護活動的基礎。
2) 系統測試及外部質量評價。外部質量因素是那些用戶能輕易觀察到的軟件特性,例如功能正確性、性能、可靠性、可用性等[2]。通過系統測試,可以針對用戶需求得到遺留系統的外部質量總體評價,以及待糾正的錯誤和缺陷列表,從而為糾錯性維護打下基礎。
3) 系統理解及內部質量評價。內部質量是指與系統內部設計和實現相關的質量特性,例如可理解性、可維護性、可擴展性等,它們對于軟件工程師而言是十分重要的[2]。通過閱讀遺留系統文檔(可能殘缺不全或質量不高)以及系統代碼,同時借助于相關輔助理解工具的支持,獲得對系統設計(如體系結構和模塊結構等)和代碼的初步理解,在此基礎上對系統的設計和實現質量進行評價,從而為預防性維護打下基礎。
這一階段首先強化了對于軟件測試的實踐。在以往的教學實踐中,我們發現學生在正向開發階段往往不太重視測試(對于自己開發的系統進行測試往往會覺得沒有必要或比較敷衍了事),且常與調試混淆。而在軟件維護實踐中,測試對象是他人開發的系統(實踐中常常發現學生對于測試、評價其他人開發的系統比較有興趣),而且測試結果直接決定了對遺留系統的外部質量評價和糾錯性改進方案,因此學生往往會認真對待。系統理解能力也非常重要。在教學實踐中,可以鼓勵學生充分運用相關輔助理解工具進行系統理解,例如Eclipse相關插件所提供的代碼UML視圖、類語法樹、調用關系圖、度量信息等輔助理解功能。
除此之外,系統理解及內部質量評價還強化了對于軟件工程設計和實現原則的認識。通過閱讀遺留系統文檔和代碼,學生們可以深切體會到好的系統設計、編碼風格以及文檔規范對于軟件開發的重要性。實踐中,他們經常會抱怨遺留系統文檔不全或不一致、設計混亂、編碼風格不好,而這些其實也正是他們自己在正向開發階段很容易出現的問題。
(2) 系統改進維護階段
系統改進維護階段將在遺留系統分析和評估基礎上,進行糾錯性和預防性維護。針對用戶需求以及一般的軟件設計和實現質量準則,從外部質量和內部質量兩個方面對遺留系統進行改進。這階段的主要實踐任務包括:
1) 糾錯性維護實施。針對系統測試過程中發現的問題,進行糾錯性維護,包括消除系統意外出錯、糾正與功能需求不一致的地方、改進系統性能、可靠性等非功能質量方面的不足。
2) 回歸測試及總結。糾錯性維護結束后,通過回歸測試驗證糾錯性維護的效果,并進行總結。
3) 預防性維護方案制定及實施。針對系統內部質量評價中發現的問題以及糾錯性維護中遇到的困難(例如難以擴展的系統結構等),制定并實施對系統的預防性維護方案,包括對系統設計和編碼質量的改進,以及對開發文檔的補充和完善等。
4) 系統評審及總結。預防性維護結束后,對系統的設計、代碼及文檔進行評審,總結改進情況以及所獲得的體會和經驗。
這一階段首先涵蓋了糾錯性維護和預防性維護實踐。其次,預防性維護實踐通過系統設計、開發文檔、編碼風格等方面的改進,強化了相關軟件工程方法和原則的訓練。
(3) 系統需求演化維護階段
前兩個階段的軟件維護實踐都還停留在原有系統基礎上,系統需求演化階段將通過用戶需求和系統環境的變化,引導學生進行完善性和適應性維護實踐。由于現實中的軟件開發一般都包含多次迭代和增量,因此這階段的維護實踐也將迭代進行多次。這階段的主要實踐任務包括:
1) 需求和系統環境變更分析。在原有系統需求基礎上,提出若干新的擴展功能要求和系統環境變更(例如改變原有的數據庫管理系統),要求學生通過與助教的溝通和交流明確需求和系統環境變更要求。
2) 系統修改方案制定及實施。根據變更要求和對系統設計、實現的理解確定系統修改方案并加以實施。
3) 系統測試。針對需求或系統環境變更進行系統測試,對系統修改進行確認,所發現的錯誤和缺陷將反饋給糾錯性維護活動。
4) 系統內部質量反饋。針對需求或系統環境變更的修改活動可以對系統的內部設計和實現質量進行檢驗,暴露設計、實現及文檔等方面的問題,這些問題將反饋給預防性維護活動。
系統需求演化維護階段除了涵蓋完善性和適應性維護實踐外,還具有以下幾個方面的作用:使學生體驗到真實軟件開發中多次迭代的增量式開發過程;通過需求變更直觀體會到可維護性、可擴展性等內部設計和實現質量的重要性;驗證改進維護階段對于改進系統內部質量的效果,加深對于良好的軟件設計、編碼和文檔習慣的認識。
3 教學方案實施
軟件工程課程實驗可以按照由淺入深的順序分為認知性導入實驗、方法性實驗和綜合實踐三個部分,其中前兩部分穿插在一個學期的軟件工程課程中進行,而綜合實踐則可以在后續的軟件實踐類課程中安排[1]。在教學實踐中,軟件維護實踐應該作為綜合實踐安排,此時學生已經有了軟件工程課程教學和一些正向開發實踐(主要包括需求分析、設計和實現)基礎。軟件維護實踐以3~5人的小組為單位,每個人可以分別擔任需求分析、設計、實現和測試等不同實踐任務。
在實踐項目選擇上,我們從此前的軟件工程課程實踐、數據庫課程實踐(數據庫應用系統)等實踐項目中選取一些具有典型性的系統實現(包括文檔和代碼等)作為軟件維護實踐候選對象。這些項目一般已經基本實現了原有的用戶需求,但在外部質量和內部設計和實現上還存在許多不足。選取這類項目的好處是由類似背景的學生完成,能夠反映許多典型的軟件實踐問題,同時相關項目學生已經有所接觸,也較為熟悉。
在軟件實踐教學中,我們選取書店管理系統等多個在以往軟件工程和數據庫等相關課程的課程實踐項目作為軟件維護實踐的對象。這些項目都是以數據庫為核心的信息管理系統,這類系統較為典型且本身的需求較容易發生變化。
(1) 遺留系統分析評估階段
此階段學生將首先借助于原始需求說明以及與客戶(由助教扮演)的交互明確系統需求。在此基礎上通過測試和文檔、代碼分析進行外部質量和內部質量評價。遺留系統外部質量上存在的主要問題包括某些功能與需求不符、運行不穩定、用戶使用不方便等。而內部質量方面的普遍問題包括類結構設計混亂、文檔缺乏或不規范、編碼質量差(命名不規范、缺少注釋)等。
本階段安排約4周時間,其中第1周用于了解遺留系統原始需求,第2周用于系統測試,后2周用于系統理解和分析。本階段要求提交系統測試報告、系統總體評價報告(包括外部質量和內部質量)。
(2) 系統改進維護階段
此階段的系統改進針對系統測試報告中所發現的錯誤和缺陷進行糾錯性維護,針對系統總體評價報告中指出的設計、編碼和文檔上的不足進行改進。初次的系統改進后,本階段的維護活動還可能在系統需求演化維護階段的反饋作用下反復多次進行(見圖1)。
本階段在每次迭代中安排約2周時間,要求提交回歸測試報告、糾錯性維護總結以及預防性維護總結。
(3) 系統需求演化維護階段
此階段的維護活動由需求或系統環境變更發起。以書店管理系統為例,遺留系統實現的基本功能包括圖書查詢、選購、訂單生成、付款(現金方式)及簡單的庫存管理等。需求變更可以包括增加信用卡支付功能(通過虛擬的銀行支付接口)、增加郵購和網上訂購功能、增加會員制折扣功能等。系統環境變更可以包括改變所用數據庫管理系統(如由Access改為MySQL)、改變國內地區標準編碼(用于標識供應商及顧客的地區)等。相應的維護活動除了滿足這些新需求及系統環境外,還可以引導學生進一步改進系統的設計和實現等。例如,為了更好的容納信用卡支付這一新的付款方式,可以從現金支付和信用卡支付中抽取出公共的支付方式類,從而改進系統的設計結構。
本階段在每次迭代中安排約2周時間,要求提交系統修改方案、測試報告和系統內部質量改進反饋報告。
這樣,在一學期的軟件實踐課程中,系統改進維護階段和系統需求演化維護階段一起可以安排3次左右的迭代,每次完成1~2項需求或系統環境變更。
我們在復旦大學計算機科學與技術學院的軟件工程本科教學實踐中利用軟件實踐課程開展軟件維護實踐教學。軟件實踐課程安排在軟件工程課程(第六學期)之后的第七學期,此時學生已經系統的學習過軟件工程、數據庫、操作系統等課程,初步具備了開展綜合性軟件開發實踐的基礎。
4 總結
軟件開發實踐是軟件工程教學的重要組成部分。傳統的軟件開發實踐教學主要以瀑布式的正向開發實踐為主,忽略了軟件維護實踐的訓練。軟件維護實踐的意義不僅在于軟件維護在現實軟件開發中的重要地位,而且可以使學生更加直觀、深刻地體會和理解相關的軟件工程方法和原則。通過遺留系統分析評估以及多次迭代的系統改進維護和需求演化維護,不僅培養了系統理解、修改等軟件維護實踐能力,還強化了軟件設計準則、編碼和文檔習慣以及軟件測試能力的培養。
參考文獻
[1] 彭鑫,趙文耘,錢樂秋.軟件工程實驗教學研究與實踐[J].計算機教育,2007,(20).
關鍵詞:軟件開發過程;項目管理
隨著信息技術的快速發展,應用軟件的功能越來越龐大,為了便于管理,把項目管理的方法引入到軟件開發過程當中,對所有的軟件活動進行有效的管理。本文按照傳統的瀑布模型從項目管理九大知識領域的角度,進行軟件管理項目的工作實踐管理。
第一階段:立項
(1)建立團隊:明確項目經理,選擇項目組成員,識別項目干系人。
(2)編寫項目任務書:明確項目的背景和目標,能夠描述出基本的項目范圍,識別并且確定整個項目的需求,能夠指出項目中干系人的期望值,確認需要交付的產品或服務,功能和性能指標。
(3)制定工作計劃:重點描述任務的分配計劃,執行的時間計劃。
(4)制定成本計劃:制定活動清單,采購計劃,人力成本計劃。
(5)制定評審流程:由項目的管理層和相關干系人制定流程。
(6)制定溝通管理:制定溝通管理。
(7)簽訂合同:立項、初驗、中驗、維保過程中確認交付的產品或者服務。
第二階段:需求的調研
(1)人員分配:分配調研人員工作任務。
(2)編寫需求規格說明書:進一步明確軟件的范圍,原型的制定(UI操作界面+UE界面設計),明確才用的開發環境和開發工具。
(3)運營指標的檢測:監控工作任務的完成情況,監控預算是否變化,監控需求的變更。
(4)時間管理:任務分解wbs,定義具體的活動,排列順序,估算工作時間。
第三階段:設計和開發
(1)人員管理:分配開發人員工作任務。
(2)編寫概要設計說明書,編寫詳細設計說明書,編寫代碼。
(3)運營指標的監控:監控工作任務的完成情況,監控預算是否變化,監控需求的變更。
第四階段:測試
(1)人員管理:分配測試人員工作任務。
(2)部署:部署生產環境。
(3)編寫功能測試測試計劃,編寫功能測試用例并執行測試,編寫功能測試報告。
(4)編寫性能測試測試計劃,錄制腳本并分析,編寫性能測試報告。
(5)測試管理:缺陷管理。
(6)運營指標的監控:功能和性能是否和需求一致,工作任務否是及時完成。
第五階段:實施
(1)人員管理:分配實施人員任務。
制定實施方案:在生產環境部署軟件的使用環境,要保證執行計劃所需的資源
(2)運營指標的監控:是否及時完成實施人員的培訓及管理工作。
(3)用戶驗證確認。
第六階段:運行和維護
(1)對項目代碼進行打包,交付。
(2)合同終結:得到項目干系人的認可。
(3)跟蹤問題,并解決問題。
(4)撰寫項目總結報告。
在對項目的綜合管理中,要制定計劃,要嚴格的執行計劃,遇到變化,要有效的進行協調和控制;在項目范圍管理中,對范圍進行定義和確認,有效的變更進行控制;對項目時間的管理就是對活動進行定義,根據活動的性質,進行排序,以及時間的估算,人員進度的安排和進度的控制;在項目成本管理中,要有資源計劃,成本估算,成本預算和成本控制;在項目質量管理就是質量計劃,質量評估和質量控制;在項目人力資源管理中強調,項目組成員的組建,干系人的識別;在項目溝通管理中,強調溝通計劃,激勵措施,執行情況報告以及信息管理;項目風險管理,強調風險分析和識別,以及風險監控;最后是采購管理,制定采購計劃,確認項目范圍內的都已經完成,合同管理及合同收尾。
軟件開發類項目通常是通過團隊合作的方式來完成的,引入了項目管理的知識,在整個項目中對工作任務的分解、估算工作時間,人員的分配、風險的監控、成本的控制、質量的把握等方面起到了很好的作用。讓項目的每個階段,都能夠在管理者的監控之下,以達到在成本、時間、質量三者的一個平衡,最終完成整個項目的開發,最終打包交付到用戶手中,合同終結。
參考文獻:
[1] 王勇、張斌譯.項目管理知識體系指南.電子工業出版社.(美)項目管理協會