第一篇:軟件工程學習總結和體會2015
西安交通大學
2015級研究生課程專題作業
軟 件
工 程 心 得專 業: 班 級: 學 號: 姓 名: 電 話:
二○一五年十月
體 會
一、軟件生命周期各階段任務目的和主要方法
在分階段總結之前,首先要明確以下三個問題:
1、什么是軟件生存周期?
軟件生存周期是指從軟件定義、開發、使用、維護到淘汰的全過程。主要包括:
(1)問題定義;(2)可行性研究;(3)需求分析;(4)概要設計;(5)詳細設計;(6)編碼;(7)測試;
(8)軟件維護。
2、軟件生存周期為什么劃分成階段?
(1)任何一個階段的具體任務不僅獨立,而且簡單,便于不同人員分工協作,從而降低整個軟件開發工作的困難程度。
(2)可以降低每個階段任務的復雜程度,簡化不同階段的聯系,有利于工程的組織管理,也便于采用良好的技術方法。
(3)使軟件開發的全過程以一種有條不紊的方式進行,保證軟件的質量,特別是提高了軟件的可維護性。
3、應該怎樣來劃分階段?
(1)每一個階段的任務盡可能獨立;(2)同一階段內的任務性質盡可能相同;
(3)每一個階段任務的開始和結束有嚴格的標準。
下面分別對各階段進行討論:
1、問題定義
目的是將用戶提出的要求具體化、定量化,任務是確定研制系統的范圍,明確研制的邊界。
方法步驟:
(1)通過調查研究,了解系統要求;
(2)需求方與開發方討論確定系統的功能、性能、可靠性、安全保密性等方面的要求,以及費用、進度等方面的要求。
2、可行性研究
可行性研究說明該軟件開發項目的實現在技術上、經濟上和社會條件上的可行性,評述為合理地達到開發目的可能選擇的各種方案,目標是用最小的代價在盡可能短的時間內確定問題是否能夠解決。
可行性研究的方法是首先需要進一步分析和澄清問題定義;然后分析員導出系統的邏輯模型;最后對未來的行動方針提出建議。
在導出邏輯模型的過程中,具體要根據以下四個方面分析可行性:
(1)經濟可行性:進行成本效益分析,評估項目的開發成本,估算開發成本是否會超過項目預期的全部利潤.分析系統開發對其它產品或利潤的影響。
(2)技術可行性:根據客戶提出的系統功能,性能及實現系統的各項約束條件,從技術的角度研究實現系統的可行性。(3)法律可行性:研究在系統開發過程中可能涉及的各種合同,侵權,責任以及各種于法律相抵觸的問題。
(4)開發方案的選擇性:提出并評價實現系統的各種看法方案.從中選出一種用于軟件項目開發。
3、需求分析
需求分析是為了有效解決用戶的需要而進行的一項工程活動,要考慮的問題是功能需求、數據需求、性能需求和接口需求,開發者承擔分析任務,核心是用戶。
軟件項目的失敗大半源于需求分析沒有做好,軟件開發人員首先應該明確用戶的意圖和要求,正確獲取用戶的需求,然后形成一個軟件需求規格說明,它是軟件開發的重要基礎。
需求分析的方法:
(1)需求獲取:獲取客戶需求,客戶泛指某個人或機構部門等,一般方法是調查,包括訪談座談、問卷、跟班和收集資料,需求規約可表達用戶的軟件價值。
(2)需求分析與規格說明:建立需求模型,它是用戶需求的圖解,一些常用的模型有:業務樹圖、用例圖、活動圖。分別用于結構化需求建模、系統業務舉例和反映系統工作流程。
(3)需求驗證:要驗證的主要內容有:有效性驗證、一致性驗證、完整性驗證、現實性驗證和可檢驗性驗證。
需求建模的方法:
(1)關聯模型
(2)面向對象模型(3)原型方法
4、系統設計
此階段主要根據需求分析的結果,對整個軟件系統進行設計,如系統框架設計,數據庫設計等,一般分為概要設計和詳細設計,好的軟件設計將為軟件程序編寫打下良好的基礎。
概要設計是對需求規格說明書中提供的軟件系統邏輯模型進行進一步的分解,從而建立軟件系統的總體結構和各個子系統間及各個模塊間的關系,定義各子系統接口界面和各模塊的功能描述,并根據設計結果產生概 要設計文檔。
概要設計在早期有模塊化方法、功能分解方法;在60年代后期提出了面向數據流和面向數據結構的設計方法;近年來又提出面向對象的設計方法等。
詳細設計過程根據概要設計形成的結果對各個模塊的內部實現進行規劃設計,并根據設計結果產生詳細設計文檔。
詳細設計主要方法是通過采用結構化和面向對象的方法從視圖、控制、模型三層模型上細化概要設計的各個模塊,并完成偽代碼為編碼階段做準備。
5、編碼和測試
編碼是將軟件設計的結果轉換成計算機可執行的程序代碼。主要方法是依據詳細設計文檔實現設計中的算法、功能、接口、數據結構,采用結構化和面向對象化的方法編寫代碼。
編碼過程中要制定統一,符合標準的編寫規范,以保證程序的可讀性,易維護性,提高程序的運行效率。
軟件設計完成后要經過嚴密的測試,以發現軟件在整個設計過程中存在的問題并加以糾正。整個測試過程分單元測試、組裝測試以及系統測試三個階段進行。
測試的方法主要有白盒測試和黑盒測試兩種。在測試過程中需要建立詳細的測試計劃并嚴格按照測試計劃進行測試,以減少測試的隨 意性。
6、軟件維護
軟件維護是軟件生命周期中持續時間最長的階段。在軟件開發完成并投入使用后,由于多方面的原因,軟件不能繼續適應用戶的要求。要延續軟件的使用壽命,就必須對軟件進行維護。
軟件的維護包括糾錯性維護和改進性維護兩個方面。
二、課程主要收獲
《軟件工程》課程強調概念和知識的理解和掌握,側重軟件項目的分析、設計、實現和維護的基本技能。比較注意“點”和“面”的結合,是一門理論性和實踐性都較強的學科。作為一名已經在IT領域工作十年之后又重返校園的大齡學生,雖然已經不是第一次學習這門課程了,去年也剛在單位取得了信息系統項目管理高級工程師資格,從另一個側面對軟件開發過程有了更深層次的理解。不過溫故而知新,這次仍然選修這門課,我還是得到了一些新的啟示。最大的收獲就是在我看來,軟件工程與其說是一門課程,不如說是一門思想,是一個如何去分析和處理問題的過程,應該說其范疇已經遠遠不止局限于該門課程,它已經成為了一個綜合的能夠解決問題的思想集合。
此外,通過對軟件開發過程的重學習,并結合之前在軟件開發管理工作中的經驗,我對自己在軟件開發主要階段管理工作中的不足有了更進一步的認識,總結了相應的管理要點,具體闡述如下:
1、概要設計
主要任務:系統應該怎樣做,或概括地說,系統應該如何實現。本階段特點:將用戶的具體要求轉為抽象的計算機軟件設計。管理要點:
通過分析對比,從多種可能的實現方案和軟件結構中選出最佳方案及最合理的,即: 設想供選擇的方案→推薦最佳方案→選取合理的方案功能分解→ 軟件設計結構 → 數據庫設計 3 確定測試要求并確定測試計劃
作為項目管理者必須從概要設計開始就應該從全局角度開始把握整個系統的進展,并必須從此階段開始,時刻從全局觀的問題來發現問題,解決問題。
2、詳細設計
主要任務:系統應該怎樣具體地做,或概括地說,系統應該如何具體地去實現所有的要求。
本階段特點:將抽象的計算機軟件設計轉為形象的,具體的,面向用戶的計算機界面設計。
管理要點:
本階段尚未涉及具體編寫程序,而是要設計出程序的“藍圖”,所以詳細設計的結果基本上決定了最終的程序代碼的質量。邏輯是否正確性能是否滿足要求是否容易閱讀和理解 作為項目管理者在詳細設計階段,應始終不忘從一名用戶的使用角度出發,審視每一個界面的詳細設計,以保證設計出來的界面以及程序能夠滿足一般用戶希望將來的系統能夠通俗易懂,簡單實用的要求。
3、編碼
主要任務:用某種程序設計語言書寫計算機能夠識別的程序。
本階段特點:將詳細設計書的內容“翻譯”成計算機語言,直接關系到整個項目的質量。
管理要點:
本階段的編碼是設計的自然結果,因此,程序的質量主要取決于軟件設計的質量。但是,程序設計語言的特性和編碼途徑也對程序的以下特性產生深遠的影響: 程序的可靠性 2 程序的可讀性 3 程序的可測試性 4 程序的可維護性
作為項目管理者在編碼階段,必須從把握進度與質量這兩個基本方面來有效地實施對項目的管理。首先應該根據項目進度計劃來合理地安排每一名作業成員的作業日程,并且隨時監督每一作業的進展情況,還需要針對項目的最新變更及時對計劃進行調整,以保證項目的按時完成。同時,在項目的進展過程中還需要通過小組討論,檢查評審等形式洞察每項作業的質量,以保證項目的保質保量完成。可以說,本階段是一名項目管理者在項目開發過程中極為忙碌也異常重要的階段。
4、測試
主要任務:通過單元測試和綜合測試來保證軟件工程的高質量。
本階段特點:盡可能早地發現并糾正差錯,往往占到軟件開發總工作量的40%以上,是保證軟件質量的關鍵。
管理要點:
軟件測試在軟件生命周期中橫跨兩個階段。通常在編寫出每個模塊之后就對其作必要的測試(稱之為單元測試),模塊的編寫者和測試者是同一人,編碼和單元測試屬于軟件生命周期的同一個階段。在此階段結束之后,對軟件系統還應該進行各種綜合測試,這是軟件生命周期的另一個獨立階段,通常由專門的測試人員來承擔這項工作。
作為項目管理者在編碼階段,必須高度重視軟件測試工作,甚至可以說應該把測試看作與編寫程序同等重要的任務來對待。在要求每一名開發人員完成自己分內的單元測試,并且監督測試人員認真進行各項綜合測試的同時,應該把自己完全當成一名本軟件工程的用戶,從用戶的角度以一種高度負責,甚至近乎苛刻的嚴格態度來對軟件進行徹底的測試。在本階段通過嚴把質量關來確保軟件工程的質量。
所以說,尤其在軟件進入具體開發階段后,能否遵循要點進行管理是很重要的。
總之,實際工作當中軟件項目為什么會失敗?為什么交付日期會一拖再拖?我覺得項目失敗只有一個原因:就是項目經理不合格。除非這個項目經理在項目開始階段就已經提出來了這個項目會失敗,或者是完全屬于項目之外不可抗拒的原因導致失敗。也許還會有一些我的同行跳出來說不服,那么請繼續:
難道是新增需求的原因導致失敗?客戶會讓你新增100個需求而要你二天交貨嗎?必然是分析設計階段沒有充分考慮好可擴展性和新增需求導致現在不可控制而失敗的!
難道是程序員人力不足導致?人都沒有到位,怎么會失敗,多少人做多少人的事,多少人做多少人的計劃,不會有失敗。
難道是程序員技能不夠?項目經理是如何面試的?怎么在項目失敗了才發現是程序員技能不夠?有問題早提出來嘛。
難道測試人員沒有做好?少來了,測試人員只是加了一道保障證明。程序很多流程都通過不了,程序還屬于開發調試階段,與測試人員有什么關系?
我曾經在單位參加一些項目,發現有這樣一個概念很多項目經理都沒有搞清楚:什么叫開發階段?我認為開發階段最多只能包括單元測試這一部分。綜合測試絕對不能屬于開發階段了,也就是說不能到了最后交付階段還有程序流程走不通,程序隨便正常操作都會失敗。程序隨便正常操作都出現好多bug屬于開發還沒有完成,絕對還沒有過單元測試階段,離綜合測試和驗收階段還早著呢。說白了,還屬于代碼審查階段。
不懂程序設計的項目經理,往往不注重code開發人員,其實這是一個嚴重的錯誤。軟件的質量來源于什么?由誰來保證?有的項目經理說是由測試人員來保證,就算測試人員的測試用例寫得很詳細,把需求中的每一個功能點都測試到了,那最后就沒有問題了嗎?當然不是,很多邏輯上的東西要程序員來保證不出問題的,而測試人員只是起一個驗證的作用,問題不應該由測試人員來發現,而應該由開發人員來發現。也就是說,我們盡量不要讓測試人員來發現問題。如果第一次測試有至少25%以上的用例通不過,那說明質量控制出了問題。這樣的版本根本就不應該拿出來進行測試。由此可見,軟件的質量是由程序員來保證的,而不是測試人員。
總的說來,一個項目的成敗與否,與項目的各個階段皆有關系:需求都不清楚,開發起來肯定是南轅北轍;分析設計不夠好,會讓程序員難以維護,隨著新增需求的增多,會導致整個系統混亂不可控制;編碼不好,整個系統不穩定是必然的,Bug也是抓不盡的;測試不做好,系統是沒有保證的,少了哪個環節都不行。
所以做軟件項目開發過程管理工作,我認為重點要放在項目計劃、進度控制、質量控制、風險預測這四個方面。不要說項目的失敗是因為新需求引起的,一個沒有新增需求和風險的項目是不存在的,承認這一點之后,我們就不會有很多怨言了。
以下針對這四個方面進行詳述:
項目計劃:沒有項目計劃,那失敗還有什么話好說?大家都知道凡事預則立,不預則廢。項目計劃一定要包括這幾方面的內容:各階段里程碑時間點,各個里程碑的輸出結果,風險預測,意外應對。計劃時間一定要提前于交貨時間,并注意風險意外是否留下足夠的應對時間和處理方案。
進度監控:對每個階段把握好,每個階段要完成的任務一定要完成,如果完不成,是什么原因導致的?我們的應對策略是什么?我們要信任別人,但是不要忘記鎖門。同樣的,別人說完成了,你不能就認為別人完成了,要看到結果才能證明完成了。有的項目經理說,我也進度監控啦,他說完成了就完成了,誰想到沒有完成?到底是程序員不誠實還是項目沒有管理好?你沒有鎖好門,能怨別人偷你東西嗎?還有一種情況就是不懂如何鎖門,根本就不知道這一階段的輸出結果是什么?當然進度監控就是一句空話了。
質量監控:也應該是分階段進行的,每一個階段的質量監控內容有所不同。
需求分析階段的質量監控就是完整而又正確的理解用戶需求,需求是否清楚可懂,寫用例的測試人員是否明白需求?
分析設計階段的質量監控就是設計是否完全滿足需求?這個設計方案是否滿足以后新功能的擴展?以及是否有考慮到新功能的意外和設備環境,運行平臺的變化?
編碼階段的質量監控就是變量命名是否規范?代碼是否可讀?是否有詳細的注釋?是否有重復代碼?要知道重復代碼是必然會造成系統不穩定,bug成群的。可變部分的代碼和不可變部分的代碼是否分離。要知道上面講的每一部分如果沒有做好,都會導致后期的產品出現大量問題。代碼階段還有一個重要的工作就是做code review代碼公開評審,你自己發現不了的問題別人也許就看得見。
單元測試階段的質量監控任務就是單元測試代碼是否測試通過?代碼覆蓋是否完全?單元測試報告提交情況如何?單元測試用例有沒有做好? 綜合測試階段質量監控任務當然就是看用例是否完全?是否全部真正執行?測試報告有沒有寫好?
回歸測試當然得看以前測試的Bug是否還在,如果還在,當然是無條件打回去重新開發。
測試階段最主要的監控就是看用例是否真正執行,是否有安全性測試?破壞性測試?異常測試,壓力測試?
以上的每個階段最好完成了才進行下一階段,否則會造成混亂出現問題的,造成想并行進行節約時間卻反而浪費了時間。
以上就是我重學《軟件工程》并結合實際工作經驗所得到的啟示,不妥之處請劉老師批評指正!
第二篇:軟件工程學習總結
軟件工程學習總結
通過一個學期系統的學習軟件工程這門課,結合與小組成員一起開發設備管理系統的經驗,讓我對軟件的開發有了更深的了解,學習到每一個軟件的開發都不僅僅是寫代碼,還有更加復雜的系統性的開發流程。
要開發一個軟件,就拿設備管理系統來說,我們不能一上手就開始寫代碼,這樣會浪費大量的人力物力財力還得不到理想的結果,首先我們應該先做好市場及需求方面的調查,了解用戶需求有助于我們開發更加實用高效的軟件,做好市場調研可以讓我們對成本、利潤、市場情況等有深層了解,讓我們做出最優決策。
調查結束后,我們要寫出詳細的報告,包括項目開發計劃書、軟件需求規格說明書等,有了這些調查結果,我們才可以系統的,條理的來編寫我們的軟件。從前我們寫代碼都非常的盲目,雜亂無章,想到哪寫到哪,浪費了大量的時間,寫的代碼結構也很松散,錯誤率高。學習軟件工程后,我們學習了多種軟件開發模型,學會了模塊化的開發方法,小組成員每人完成不同的模塊,最后綜合起來,這樣能夠節省大量的時間,縮短開發時間,使代碼結構更加緊湊,易于管理維護。如果說代碼是一種工具的話,那么軟件工程就是使用工具的經驗指導,他能指導我們更好的使用這個工具,發揮它最大的潛能,幫助我們完成項目,不管使用什么程序語言,軟件工程教給我們的開發方法都無條件適用,我們需要認真學習理解這門課程,它將伴隨我們在程序開發的路上走下去。
第三篇:軟件工程實施體會
軟件工程實施體會
——本學期對軟件工程實驗使我學會的
軟件工程項目是需要團體作業才能夠完成的。團體作業就需要交流,有交流,就必然會有合作;有合作,就需要有分工;有分工,就需要有協調;有所有這些,就需要有管理。然而一個人的項目是否不需要管理?當然不是,因為有文檔,有代碼,有靈感,有經驗,等等都需要管理。只是此刻的管理是自己完成的,可以更簡單一點。我們已經有過一遍又一遍的調試以前已經fix過的bug體驗,也有過一遍又一遍的查找以前自己實現過的技術的經歷。軟件工程的理論,在開發過程中的作用,就是指導如何做好管理,以取得軟件的可用性、正確性和合理性。如果我們清楚知道這是它的目標,就可以拋開一些對自己不適用的枝節。
那么我們如何實現它呢?
我認為軟件工程中最重要的,最有實際意義的,是它界定了工作職能,從而也確定了責任歸屬。什么意思?說白了,就是什么人做什么事,出了問題誰負責。那么它是怎么界定工作職能的?是通過對軟件開發流程的劃分來實現的。軟件工程把軟件的開發劃分成很多個相對獨立的階段,每一個階段都有相關的人員來實現,也就有相關的人員來負責。分工不清,責權不明,是導致管理混亂的最主要的因素。所以即使是兩個人的項目,也是需要軟件工程來指導的,因為通過它,可以更好的知道如何可以合理分工,劃分工作職權以取得最終的成果。當然,走教條主義的道路是非常愚蠢的。
軟件工程是針對“軟件危機”提出來的。它是一種工程,把經驗和理論應用到實踐中來,解決軟件開發中出現的各種問題。這是什么意思?就是說,軟件工程是用來解決實際問題的。如果軟件開發中沒有遇到管理問題,軟件工程就不需要管理的內容;如果軟件開發中沒有遭遇文檔混亂,軟件工程就不需要文檔的部分。但是如果很幸運的遭遇到了這些,那么這一切都是不可或缺的。軟件工程不是一個固定的呆板的框框,而是一個有彈性的概念。
所以,如果不是要去申請iso或是cmm認證,完全不必要一板一眼的按照iso或是cmm的規范去做。所謂“有企業特色的軟件工程”,完全可以從吸收現有的模式和規范中完善起來。但這并不是說所有在開發過程中出現的都是軟件工程,只有那些能引導開發走向成功的才是真正有意義的軟件工程。其他的,最多只是失敗的嘗試。
軟件工程實施的時機;
首先要知道軟件工程,理解軟件工程;然后要了解現有的軟件工程的模式和規范。ISO、CMM或是Agility,都定義了一套規范。這些規范是經驗與技術,以及理論的積累。它們存在很多合理的、可行的模式,可以引用和參考;但銀彈是沒有的。當然,我們可以重頭再來,造他們造過的輪子,摔他們摔過的跤;但很明顯,這是不必要的。
實施的最好方法,也是最可行的方法,成本最小的方法,是根據開發的客觀的因素,修改那些規范,以符合我們的開發過程;但是最主要的,是修改我們的主觀認識,以符合那些規范;而最重要的,是在實施中發現那些規范不合理的地方,并改正它。我們擔心過小的項目應用軟件工程是否會陷入官僚主義,從而加重項目的負擔?我們再來看什么是軟件工程?軟件工程并沒有定義什么才是軟件工程!也沒有定義軟件工程自身的規模。軟件工程的意義在于對開發階段的劃分,以及分工和責任歸屬。這與項目的規模沒有什么沖突。相反,越是小的項目越是需要軟件工程的管理。
軟件開發的一個共識,是把一個大的項目劃分成一些小的模塊,再把小的模塊劃分成更小的模塊。如果這些小模塊是獨立的(或者原來就是一個獨立的項目),那么軟件工程至少可以提高它的重用性。對于一個軟件工程觀念不深的團隊,不要期望他們在接手大的項目的時候可以使用軟件工程,如果他們在小項目中不愿使用的話。前者的復雜度不是他們可以想象和承受的。軟件工程對工作量有什么影響?針對那些在不使用軟件工程管理的項目中很輕松的人而言的。軟件工程會使他們要么失業,要么負起責任來。相對工程師而言,他們會從混亂的毫無頭緒的狀態中解放出來,他們的工作會變得有效率。損失的是以前尸位素餐的人將暴露出來——這可能是它的唯一的缺陷,同時也是它受到很多企業/個人抵制的可能原因之一。
第四篇:學習軟件工程的心得與體會
學習軟件工程的心得體會
整本書的內容邏輯很清晰明了,由淺入深循序漸進,首先我就大概描述下我們所學的內 容,第一章是從整體分析軟件工程這門學科的發展和所處的社會環境,接著后面的幾章深入分析了軟件開放過程和模式、軟件項目管理、計算機工程、需求分析、結構化分析建模以及基于UML面向對象分析建模等。接著我就詳細介紹下我對這門課程知識點的理解概括:
軟件工程是指導計算機軟件開發和維護的工程學科。
軟件生存周期:一個軟件從定義到開發、使用和維護,直到最終被棄用,要經歷一個漫長的時期,通常把軟件經歷的這個漫長的時期稱為生存周期。軟件的生存周期可分為八個階段:①問題定義;②可行性研究;③需求分析;④總體(概要)設計;⑤詳細設計;⑥編碼與單元測試;⑦綜合測試;⑧軟件維護; 瀑布模式:原型進化模式:增量模式:螺旋模式:
軟件開發的整個過程:①需要項目團隊,組建優秀的團隊可以開發出更搞質量的軟件產品。任務開發團隊要求小而精,成員大多在8人以內,主要成員有項目負責人、開發人員、資料管理員和軟件測試員。②項目計劃是為了使軟件開發各項工作有秩序地進行,包括任務分配和基于里程碑的進度安排,甘特圖和任務網絡圖是用來描述進度計劃的工具。項目計劃書可以作為軟件開發的工作指南。③項目成本估算,由于項目有來自各方面的成本包括工資開支、場地費、差旅費、設備費和資料費等,但是軟件主要是對人力成本的估算,常用的方法有程序代碼成本估算法等。④軟件風險管理包括很多不確定的風險因素,如計劃風險、管理風險、需求風險、技術風險、人員風險、產品風險、用戶風險和商業風險等等,而風險管理的主要任務是:風險識別、風險評估、和風險防范。⑤軟件文檔管理,軟件文檔是工程模式軟件開發的成果體現,包括技術文檔、管理文檔和用戶文檔。⑥軟件配置管理與軟件質量管理,包括配置規劃、軟件變更控制、軟件版本控制和質量控制計劃。
《軟件工程》課程既強調基本概念和基本知識的理解和掌握,又側重軟件項目的分析、設計、實現和維護的基本技能。比較注意“點”和“面”的結合。我還是蠻喜歡這門課的,通過對這門課的學習讓我意識到理論學習很重要,實踐更重要,實踐是檢驗真理的唯一標準,只有將理論與實際結合,才更能發揮我們所學的知識的作用,更能直接的創造效益,社會和國家做出貢獻。
第五篇:軟件工程課程設計個人體會
數學與信息工程學院
項目名稱: 實驗室設備管理系統 專業班級:11計教1班
學號:1129020025 姓名:蔣一瑭
承擔角色:美工,問題處理 組號:08 同組組長:鄧磊
同組其他成員:王宇翔 馬富偉 江濤 指導教師:鐘美
完成起止日期:2014.6.12 《軟件工程課程設計個人體會》 1.美化軟件和對在設計過程中所遇到的問題進行處理 2.在設計是會出現兩種錯誤,一種是系統部分自定義錯誤和數據庫錯誤。系統部分自定義錯誤在權限方面,管理員出現錯誤,而輸入方面用戶帳號和密碼出錯,查找方面找不到符合要求的記錄。對于數據庫,代碼出錯。
對于系統部分 自定義錯誤,需要添加/修改操作只能給幾十對輸入數據進行驗真。分析錯誤的類新。并給出相應的錯誤提示語句。
對于數據庫錯誤,可以在可能出錯的地方中輸入相應的出錯語句,并將程序重置,最后返回輸入階段。
此外,還有未解決的問題:未添加設備選購數量屬性,輸入賬戶密碼后,退出登錄后,賬戶密碼自動填充。
至于美工方面,就添了一張圖片,一切從簡,只留必須要留下的。
3.軟件工程課程設計課程設想心得體味,這也激起了我爾后勤奮進修的樂趣,我想這將對我以后的進修發作主動的影響。其次,此次課程設想讓我充實熟悉到團隊協作的主要性,只要合作協作才干保證整個項目標有條不絮。經過此次設想,我懂得了進修的主要性,體會到實際學問與實際相連系的主要意義,學會了堅持、耐心和勤奮,這將為自己爾后的進修和任務做出了最好的表率。我感受作為一名軟件工程專業的先生,此次課程設想是很故意義的。更主要的是若何把自己日常平凡所學的工具利用到理想中。固然自己關于這門課懂的并不多,良多根本的工具都還沒有很好的放縱,感受很難,也沒有很有效的法子經過自身去了解,可是靠著這一個多禮拜的“進修”,在小組同窗的輔佐和解說下,漸漸對這門課逐漸發作了些許的樂趣,自己起頭自動進修并逐漸從根本漸漸起頭弄懂它。
所以我以為此次的課程設想意義很深,和其他4位同窗的配合進修、配合、勤奮的進程也很歡快,別的還要感謝感動教員的耐心教育。