導航:首頁 > 工程技術 > 軟體工程經濟學課程總結

軟體工程經濟學課程總結

發布時間:2021-08-15 19:00:20

❶ 如何學好軟體工程

這個東西關鍵是要認真聽課,同時要多做總結,注意聯想。可以使用思維腦圖等的學習方法來加強學習。

❷ 談談你對「軟體工程」概念的認識,總結課程的全部內容。課本見圖(大學)

軟體工程首先給我定義是從事IT行業,
會給我一個工程性的思想且有很多實踐,
至少自己努力了不會出現動手能力差的問題。
第一點保證了我會在找工作時不會愁,因為國情決定軟體人才太缺了。
第二點保障可能能拿到高工資的行業。
有這兩點,我覺得其他都不重要了,因為當你有了錢,你的人品不差的時候其他都來了,如房子,車子,地位,尊重等。

事實沒有騙我,在軟體學院的學習給我很好地補充了軟體工程思想
希望能幫到你,有什麼不懂的歡迎追問我
採納下好嗎,謝謝

❸ 軟體工程該學習些什麼

書的話,如果是入門,我推薦《C++入門經典》(第三版),這本書由淺入深,章節安排很合理。樓上各位提到的《C++ Primer》這本我覺得不適合初學者,因為章節安排不是循序漸進的。至於譚浩強的書,我沒看過他寫的C++,所以不做評論。但是我看過他寫的C語言的書,被人稱之為「方言版的C語言」,雖然好懂,但是不標準的寫法甚至錯誤的寫法,懂了又有何用。如果是有C++基礎了,那麼,可以看《C++編程思想》、《C++編程規范》等等。其實學習的重點放在哪裡那是根據個人習慣及熟練程度而定,不要太看重,多看看書,你會有所體會的。但是,注意,一次主攻一本書,不能雜,另外的書只能當做參考。上面提到的幾本書我都有電子版的,你提供郵箱,我可以發給你。反正我都是看的電子版的,畢竟正版書太貴了,盜版也難找到。

程序設計重在實踐。編寫代碼不用太急,慢慢來,從簡單的寫起,我不建議首先進行手寫,那樣沒實際意義,即使再簡單,拿到計算機上去跑,然後逐步修改並添加功能。就拿我當初看到 vector 這個東西時來說吧,我覺得 push_back() 這個成員函數很好用,所以我就寫了那麼兩三行,只是為了看看 push_back() 這個成員函數的作用。所以,我覺得,書上的代碼在最開始沒必要完整的寫一遍,因為那些可能涉及到還沒有看到的內容。看到了新東西,就可以簡單的自己去驗證一下那麼一點小功能,像這樣小的東西寫多了自然就熟悉了,之後寫稍微長的代碼就更熟練。同時,對於書上的一些代碼,先不要急這自己獨立寫出來,畢竟別人寫書的,對於出版出來的代碼應該是經過精心設計的,其中很可能就用到一些技巧,剛開始寫不出很正常,主要是因為不熟練。
慢慢的,當你對於C++中的新東西有個比較清楚的認識後(不用急著記住每個新東西),你可以將以前自己用C寫過的代碼改成C++方式,比如,一般的數組用vector代替,C風格的字元串用C++中的 string 類型替代,這樣寫出C++版本的代碼。如果以前用C寫過得東西不多,你可以將書上的習題來練習。寫多了,熟悉了,以後寫代碼就逐漸轉變成C++的代碼風格。由於C++標准庫很強大,所以,以前很多C代碼都可以修改得更精簡,看起來更舒服!
到了後面的高級內容,開始可以就簡單的將書上完整的代碼抄寫一遍(不是手寫),然後進行一定得調試。此時候要注意的不是代碼的具體功能,而是其中代碼風格。比如,類,注意構造函數,析構函數該怎樣寫,成員的對外可見性如何寫,等等。創造的話,如果看完了類,並且懂得類書寫的基本風格,那麼,你可以用自己的方法寫出一個 vector 類,當然,此時不需要處理異常,不需要完整的實現標准版本的功能,就實現諸如 push_back(), size(), empty()等功能,然後用自己寫的類進行別的操作。之後,諸如deque,list等等都可以用自己的方法實現。同時,這時候寫的代碼也可以留作以後逐步完善,等你非常牛逼時候,就寫出了不遜色於標准庫的代碼了。

總之,我認為,不因為寫那麼兩三行代碼拿到電腦上去跑就嫌麻煩,多在實際中跑自己寫的代碼,由簡單的寫起,由兩三行寫起。C++對於C來說有很多新東西,每看到一個,就自己寫寫去驗證,一個一個來,慢慢的組合那些小的細節以實現更多功能。此時,不要太看重演算法,數據結構,就像英語,學習語法時,我們主要學應用語法造句,而不是學造文章,文章是之後的事。這只是個學習的先後次序問題

最後,代碼風格一定要標准規范,可以附加看看《C++編程規范》等。不懂的問題及時在書上或者到網上搜查。

❹ 關於軟體工程這門課程

軟體工程一直以來都缺乏一個統一的定義,很多學者、組織機構都分別給出了自己的定義:

Boehm:運用現代科學技術知識來設計並構造計算機程序及為開發、運行和維護這些程序所必需的相關文件資料。

IEEE:軟體工程是開發、運行、維護和修復軟體的系統方法。

Fritz Bauer:建立並使用完善的工程化原則,以較經濟的手段獲得能在實際機器上有效運行的可靠軟體的一系列方法。

軟體工程學的內容
軟體工程學的主要內容是軟體開發技術和軟體工程管理
軟體開發技術包含軟體工程方法學、軟體工具和軟體開發環境;軟體工程管理學包含軟體工程經濟學和軟體管理學。

軟體工程基本原理

著名軟體工程專家B.Boehm綜合有關專家和學者的意見並總結了多年來開發軟體的經驗,於1983年在一篇論文中提出了軟體工程的七條基本原理。
(1)用分階段的生存周期計劃進行嚴格的管理。
(2)堅持進行階段評審。
(3)實行嚴格的產品控制。
(4)採用現代程序設計技術。
(5)軟體工程結果應能清楚地審查。
(6)開發小組的人員應該少而精。
(7)承認不斷改進軟體工程實踐的必要性。
B.Boehm指出,遵循前六條基本原理,能夠實現軟體的工程化生產;按照第七條原理,不僅要積極主動地採納新的軟體技術,而且要注意不斷總結經驗。
軟體工程(SoftWare Engineering)的框架可概括為:目標、過程和原則。
(1)軟體工程目標:生產具有正確性、可用性以及開銷合宜的產品。正確性指軟體產品達到預期功能的程度。可用性指軟體基本結構、實現及文檔為用戶可用的程度。開銷合宜是指軟體開發、運行的整個開銷滿足用戶要求的程度。這些目標的實現不論在理論上還是在實踐中均存在很多待解決的問題,它們形成了對過程、過程模型及工程方法選取的約束。
(2)軟體工程過程:生產一個最終能滿足需求且達到工程目標的軟體產品所需要的步驟。軟體工程過程主要包括開發過程、運作過程、維護過程。它們覆蓋了需求、設計、實現、確認以及維護等活動。需求活動包括問題分析和需求分析。問題分析獲取需求定義,又稱軟體需求規約。需求分析生成功能規約。設計活動一般包括概要設計和詳細設計。概要設計建立整個軟體系統結構,包括子系統、模塊以及相關層次的說明、每一模塊的介面定義。詳細設計產生程序員可用的模塊說明,包括每一模塊中數據結構說明及加工描述。實現活動把設計結果轉換為可執行的程序代碼。確認活動貫穿於整個開發過程,實現完成後的確認,保證最終產品滿足用戶的要求。維護活動包括使用過程中的擴充、修改與完善。伴隨以上過程,還有管理過程、支持過程、培訓過程等。
(3)軟體工程的原則是指圍繞工程設計、工程支持以及工程管理在軟體開發過程中必須遵循的原則。

軟體工程必須遵循什麼原則

圍繞工程設計、工程支持以及工程管理已提出了以下四條基本原則:

(1)選取適宜的開發模型

該原則與系統設計有關。在系統設計中,軟體需求、硬體需求以及其它因素間是相互制約和影響的,經常需要權衡。因此,必需認識需求定義的易變性,採用適當的開發模型,保證軟體產品滿足用戶的要求。

(2)採用合適的設計方法

在軟體設計中,通常需要考慮軟體的模塊化、抽象與信息隱蔽、局部化、一致性以及適應性等特徵。合適的設計方法有助於這些特徵的實現,以達到軟體工程的目標。

(3)提供高質量的工程支撐

工欲善其事,必先利其器。在軟體工程中,軟體工具與環境對軟體過程的支持頗為重要。軟體工程項目的質量與開銷直接取決於對軟體工程所提供的支撐質量和效用。

(4)重視軟體工程的管理

軟體工程的管理直接影響可用資源的有效利用,生產滿足目標的軟體產品以及提高軟體組織的生產能力等問題。因此,僅當軟體過程予以有效管理時,才能實現有效的軟體工程。

軟體工程是指導計算機軟體開發和維護的工程學科。

採用工程的概念、原理、 技術和方法來開發與維護軟體,把經過時間考驗而證明正確的管理技術和當前能夠 得到的最好的技術方法結合起來,這就是軟體工程。

軟體工程強調使用生存周期方法學和各種結構分析及結構設計技術。它們是在七十年代為了對付應用軟體日益增長的復雜程度、漫長的開發周期以及用戶對軟體產品經常不滿意的狀況而發展起來的。人類解決復雜問題時普遍採用的一個策略就是「各個擊破」,也就是對問題進行分解然後再分別解決各個子問題的策略。軟體工程採用的生存周期方法學就是從時間角度對軟體開發和維護的復雜問題進行分解,把軟體生存的漫長周期依次劃分為若干個階段,每個階段有相對獨立的任務,然後逐步完成每個階段的任務。採用軟體工程方法論開發軟體的時候,從對任務的抽象邏輯分析開始,一個階段一個階段地進行開發。前一個階段任務的完成是開始進行後一個階段工作的前提和基礎,而後一階段任務的完成通常是使前一階段提出的解法更進一步具體化,加進了更多的物理細節。每一個階段的開始和結束都有嚴格標准,對於任何兩個相鄰的階段而言,前一階段的結束標准就是後一階段的開始標准。在每一個階段結束之前都必須進行正式嚴格的技術審查和管理復審,從技術和管理兩方面對這個階段的開發成果進行檢查,通過之後這個階段才算結束;如果檢查通不過,則必須進行必要的返工,並且返工後還要再經過審查。審查的一條主要標准就是每個階段都應該交出「最新式的」(即和所開發的軟體完全一致的)高質量的文檔資料,從而保證在軟體開發工程結束時有一個完整准確的軟體配置交付使用。文檔是通信的工具,它們清楚准確地說明了到這個時候為止,關於該項工程已經知道了什麼,同時確立了下一步工作的基礎。此外,文檔也起備忘錄的作用,如果文檔不完整,那麼一定是某些工作忘記做了,在進入生存周期的下一階段之前,必須補足這些遺漏的細節。在完成生存周期每個階段的任務時,應該採用適合該階段任務特點的系統化的技術方法——結構分析或結構設計技術。

把軟體生存周期劃分成若干個階段,每個階段的任務相對獨立,而且比較簡單,便於不同人員分工協作,從而降低了整個軟體開發工程的困難程度;在軟體生存周期的每個階段都採用科學的管理技術和良好的技術方法,而且在每個階段結束之前都從技術和管理兩個角度進行嚴格的審查,合格之後才開始下一階段的工作,這就使軟體開發工程的全過程以一種有條不紊的方式進行,保證了軟體的質量,特別是提高了軟體的可維護性。總之,採用軟體工程方法論可以大大提高軟體開發的成功率,軟體開發的生產率也能明顯提高。

目前劃分軟體生存周期階段的方法有許多種,軟體規模、種類、開發方式、開發環境以及開發時使用的方法論都影響軟體生存周期階段的劃分。在劃分軟體生存周期的階段時應該遵循的一條基本原則就是使各階段的任務彼此間盡可能相對獨立,同一階段各項任務的性質盡可能相同,從而降低每個階段任務的復雜程度,簡化不同階段之間的聯系,有利於軟體開發工程的組織管理。一般說來,軟體生存周期由軟體定義、軟體開發和軟體維護三個時期組成,每個時期又進一步劃分成若干個階段。下面的論述主要針對應用軟體,對系統軟體也基本適用。

軟體定義時期的任務是確定軟體開發工程必須完成的總目標;確定工程的可行性,導出實現工程目標應該採用的策略及系統必須完成的功能;估計完成該項工程需要的資源和成本,並且制定工程進度表。這個時期的工作通常又稱為系統分析,由系統分析員負責完成。軟體定義時期通常進一步劃分成三個階段,即問題定義、可行性研究和需求分析。

開發時期具體設計和實現在前一個時期定義的軟體,它通常由下述四個階段組成:總體設計,詳細設計,編碼和單元測試,綜合測試。

維護時期的主要任務是使軟體持久地滿足用戶的需要。具體地說,當軟體在使用過程中發現錯誤時應該加以改正;當環境改變時應該修改軟體以適應新的環境;當用戶有新要求時應該及時改進軟體滿足用戶的新需要。通常對維護時期不再進一步劃分階段,但是每一次維護活動本質上都是一次壓縮和簡化了的定義和開發過程。

下面扼要介紹軟體生存周期每個階段的基本任務和結束標准。

1問題定義

問題定義階段必須回答的關鍵問題:「要解決的問題是什麼?」如果不知道問題是什麼就試圖解決這個問題,顯然是盲目的,只會白白浪費時間和金錢,最終得出的結果很可能是毫無意義的。盡管確切地定義問題的必要性是十分明顯的,但是在實踐中它卻可能是最容易被忽視的一個步驟。

通過問題定義階段的工作,系統分析員應該提出關於問題性質、工程目標和規模的書面報告。通過對系統的實際用戶和使用部門負責人的訪問調查,分析員扼要地寫出他對問題的理解,並在用戶和使用部門負責人的會議上認真討論這份書面報告,澄清含糊不精的地方,改正理解不正確的地方,最後得出一份雙方都滿意的文檔。

問題定義階段是軟體生存周期中最簡短的階段,一般只需要一天甚至更少的時間。

2可行性研究

這個階段要回答的關鍵問題:「對於上一個階段所確定的問題有行得通的解決辦法嗎?」為了回答這個問題,系統分析員需要進行一次大大壓縮和簡化了的系統分析和設計的過程,也就是在較抽象的高層次上進行的分析和設計的過程。

可行性研究應該比較簡短,這個階段的任務不是具體解決問題,而是研究問題的范圍,探索這個問題是否值得去解,是否有可行的解決辦法。

在問題定義階段提出的對工程目標和規模的報告通常比較含糊。可行性研究階段應該導出系統的高層邏輯模型(通常用數據流圖表示),並且在此基礎上更准確、更具體地確定工程規模和目標。然後分析員更准確地估計系統的成本和效益,對建議的系統進行仔細的成本/效益分析是這個階段的主要任務之一。

可行性研究的結果是使用部門負責人做出是否繼續進行這項工程的決定的重要依據,一般說來,只有投資可能取得較大效益的那些工程項目才值得繼續進行下去。可行性研究以後的那些階段將需要投入要多的人力物力。及時中止不值得投資的工程項目,可以避免更大的浪費。

3需求分析

這個階段的任務仍然不是具體地解決問題,而是准確地確定「為了解決這個問題,目標系統必須做什麼」,主要是確定目標系統必須具備哪些功能。

用戶了解他們所面對的問題,知道必須做什麼,但是通常不能完整准確地表達出他們的要求,更不知道怎樣利用計算機解決他們的問題;軟體開發人員知道怎樣使用軟體實現人們的要求,但是對特定用戶的具體要求並不完全清楚。因此系統分析員在需求分析階段必須和用戶密切配合,充分交流信息,以得出經過用戶確認的系統邏輯模型。通常用數據流圖、數據字典和簡要的演算法描述表示系統的邏輯模型。

在需求分析階段確定的系統邏輯模型是以後設計和實現目標系統的基礎,因此必須准確完整地體現用戶的要求。系統分析員通常都是計算機軟體專家,技術專家一般都喜歡很快著手進行具體設計,然而,一旦分析員開始談論程序設計的細節,就會脫離用戶,使他們不能繼續提出他們的要求和建議。較件工程使用的結構分析設計的方法為每個階段都規定了特定的結束標准,需求分析階段必須提供完整准確的系統邏輯模型,經過用戶確認之後才能進入下一個階段,這就可以有效地防止和克服急於著手進行具體設計的傾向。

4總體設計

這個階段必須回答的關鍵問題是:「概括地說,應該如何解決這個問題?」

首先,應該考慮幾種可能的解決方案。列如,目標系統的一些主要功能是用計算機自動完成還是用人工完成;如果使用計算機,那麼是使用批處理方式還是人機交互方式;信息存儲使用傳統的文件系統還是資料庫……。通常至少應該考慮下述幾類可能的方案:

低成本的解決方案。系統只能完成最必要的工作,不能多做一點額處的工作。

中等成本的解決方案。這樣的系統不僅能夠很好地完成預定的任務,使用起來很方便,而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求,但是系統分析員根據自己的知識和經驗斷定,這些附加的能力在實踐中將證明是很有價值的。

高成本的「十全十美」的系統。這樣的系統具有用戶可能希望有的所有功能和特點。

系統分析員應該使用系統流程圖或其他工具描述每種可能的系統,估計每種方案的成本和效益,還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 (最佳方案),並且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統,則可以著手完成本階段的另一項主要工作。

上面的工作確定了解決問題的策略以及目標系統需要哪些程序,但是,怎樣設計這些程序呢?結構設計的一條基本原理就是程序應該模塊化,也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成。總體設計階段的第二項主要任務就是設計軟體的結構,也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟體的結構。

5詳細設計

總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化,也就是回答下面這個關鍵問題:「應該怎樣具體地實現這個系統呢?」

這個階段的任務還不是編寫程序,而是設計出程序的詳細規格說明。這種規格說明的作用很類似於其他工程領域中工程師經常使用的工程藍圖,它們應該包含必要的細節,程序員可以根據它們寫出實際的程序代碼。

通常用HIPO圖(層次圖加輸入/處理/輸出圖)或PDL語言(過程設計語言)描述詳細設計的結果。

6編碼和單元測試

這個階段的關鍵任務是寫出正確的容易理解、容易維護的程序模塊。

程序員應該根據目標系統的性質和實際環境,選取一種適當的高級程序設計語言(必要時用匯編語言),把說細設計的結果翻譯成用選定的語言書寫的程序,並且仔細測試編寫出的每一個模塊。

7綜合測試

這個階段的關鍵任務是通過各種類型的測試(及相應的調試)使軟體達到預定的要求。

最基本的測試是集成測試和驗收測試。所謂集成測試是根據設計的軟體結構,把經過單元測試檢驗的模塊按某種選定的策略裝配起來,在裝配過程中對程序進行必要的測試。所謂驗收測試則是按照規格說明書的規定(通常在需求分析階段確定),由用戶(或在用戶積極參加下)對目標系統進行驗收。

必要時還可以再通過現場測試或平行運行等方法對目標系統進一步測試檢驗。

為了使用戶能夠積極參加驗收測試,並且在系統投入生產性運行以後能夠正確有效地使用這個系統,通常需要以正式的或非正式的方式對用戶進行培訓。

通過對軟體測試結果的分析可以預測軟體的可靠性;反之,根據對軟體可靠性的要求也可以決定測試和調試過程什麼時候可以結束。

應該用正式的文檔資料把測試計劃、詳細測試方案以及實際測試結果保存下來,做為軟體配置的一個組成成分。

8軟體維護

維護階段的關鍵任務是,通過各種必要的維護活動使系統持久地滿足用戶的需要。

通常有四類維護活動:改正性維護,也就是診斷和改正在使用過程中發現的軟體錯誤;適應性維護,即修改軟體以適應環境的變化;完善性維護,即根據用戶的要求改進或擴充軟體使它更完善;預防性維護,即修改軟體為將來的維護活動預先做准備。

雖然沒有把維護階段進一步劃分成更小的階段,但是實際上每一項維護活動都應該經過提出維護要求(或報告問題),分析維護要求,提出維護要求,提出維護方案,審批維護方案,確定維護計劃,修改軟體設計,修改程序,測試程序,復查驗收等一系列步驟,因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

都應該經過提出維護要求(或報告問題),分析維護要求,提出維護要求,提出維護方案,審批維護方案,確定維護計劃,修改軟體設計,修改程序,測試程序,復查驗收等一系列步驟,因此實質上是經歷了一次壓縮和簡化了的軟體定義和開發的全過程。

❺ 對所學軟體工程課程各部分內容的目的、作用、主要內容等進行總結,

1、軟體工程是一門研究用工程化方法構建和維護有效的、實用的和高質量的軟體的學科。它涉及程序設計語言、資料庫、軟體開發工具、系統平台、標准、設計模式等方面。
在現代社會中,軟體應用於多個方面。典型的軟體有電子郵件、嵌入式系統、人機界面、辦公套件、操作系統、編譯器、資料庫、游戲等。同時,各個行業幾乎都有計算機軟體的應用,如工業、農業、銀行、航空、政府部門等。這些應用促進了經濟和社會的發展,也提高了工作效率和生活效率 。
2、
開發流程
▪ 需求分析
▪ 概要設計
▪ 詳細設計
▪ 編碼
▪ 測試
▪ 軟體交付
▪ 驗收
▪ 維護
3、軟體架構(software
architecture)是一系列相關的抽象模式,用於指導大型軟體系統各個方面的設計。 軟體架構是一個系統的草圖。軟體架構描述的對象是直接構成系
統的抽象組件。各個組件之間的連接則明確和相對細致地描述組件之間的通訊。在實現階段,這些抽象組件被細化為實際的組件,比如具體某個類或者對象。在面向
對象領域中,組件之間的連接通常用介面_(計算機科學)來實現。
軟體體系結構是構建計算機軟體實踐的基礎。與建築師設定建築項目的設計原則和目標,作為繪圖員畫圖的基礎一樣,一個軟體架構師或者系統架構師陳述軟體構架以作為滿足不同客戶需求的實際系統設計方案的基礎。
軟體構架是一個容易理解的概念,多數工程師(尤其是經驗不多的工程師)會從直覺上來認識它,但要給出精確的定義很困難。特別是,很難明確地區分設計和構架:構架屬於設計的一方面,它集中於某些具體的特徵。
在「軟體構架簡介」中,David Garlan 和 Mary Shaw
認為軟體構架是有關如下問題的設計層次:「在計算的演算法和數據結構之外,設計並確定系統整體結構成為了新的問題。結構問題包括總體組織結構和全局控制結
構;通信、同步和數據訪問的協議;設計元素的功能分配;物理分布;設計元素的組成;定標與性能;備選設計的選擇。
但構架不僅是結構;IEEE Working Group
on Architecture 把其定義為「系統在其環境中的最高層概念」。構架還包括「符合」系統完整性、經濟約束條件、審美需求和樣式。它並不僅注
重對內部的考慮,而且還在系統的用戶環境和開發環境中對系統進行整體考慮,即同時注重對外部的考慮。
在Rational Unified Process 中,軟體系統的構架(在某一給定點)是指系統重要構件的組織或結構,這些重要構件通過介面與不斷減小的構件與介面所組成的構件進行交互。
從和目的、主題、材料和結構的聯繫上來說,軟體架構可以和建築物的架構相比擬。一個軟體架構師需要有廣泛的軟體理論知識和相應的經驗來事實和管
理軟體產品的高級設計。軟體架構師定義和設計軟體的模塊化,模塊之間的交互,用戶界面風格,對外介面方法,創新的設計特性,以及高層事物的對象操作、邏輯
和流程。
一般而言,軟體系統的架構(Architecture)有兩個要素:
它是一個軟體系統從整體到部分的最高層次的劃分。
一個系統通常是由元件組成的,而這些元件如何形成、相互之間如何發生作用,則是關於這個系統本身結構的重要信息。
詳細地說,就是要包括架構元件(Architecture Component)、聯結器(Connector)、任務流(Task-flow)。
所謂架構元素,也就是組成系統的核心"磚瓦",而聯結器則描述這些元件之間通訊的路徑、通訊的機制、通訊的預期結果,任務流則描述系統如何使用這些元件和
聯結器完成某一項需求。
建造一個系統所作出的最高層次的、以後難以更改的,商業的和技術的決定。
建造一個系統之前會有很多的重要決定需要事先作出,而一旦系統開始進行詳細設計甚至建造,這些決定就很難更改甚至無法更改。顯然,這樣的決定必定是有關系統設計成敗的最重要決定,必須經過非常慎重的研究和考察。
4、自己寫了

❻ 辦公室軟體基礎課程總結怎麼寫

1、課程背景隨著信息技術的發展,計算機技術的普及,掌握簡單的打字已經不能滿足社會的需要了,說小點也已經不能滿足自己的需要了,上一些課需要用到電子稿件,比如WORD,PPT,等,你不會編輯不會演示就不能吸引同學的眼球,就不能達到講課的效果,比如公共經濟學、區域經濟學都需要用到相關知識,所以學校開了辦公軟體這門課是適應時代的需要,更是適應了學習的需要,是一門輔助性的學科,是一個實用的工具!2、 本課程是這學期新增的一門課,我認為是大學最實用的一門課程!主要涉及到了計算機的一些實用操作,包括高級查找與替換、使用WORD樣式提高工作效率、WORD模板應用技術、編輯長文檔、書稿排版技巧、動態演示文稿製作以及製作豐富的幻燈片。本課程總共18課時,平時一周一節課,單周理論課,雙周上機課!由宋慶軍老師負責授課!平時考核為每次上機交一份實驗報告,期末考核就是本總結!3、 豐富的教學資源運用多媒體教學擺脫了傳統的教學模式,使課程更具吸引力,上機課硬體設施較好,良好的資源環境方便學生更好的完成了課程內容!為更好地提高課程質量提供了保證!4、 教學質量良好的硬體設施與良好的師資隊伍保證了課程任務的圓滿完成,但是在教學方式上面老師還有待改進,理論與實驗想分離這是最大的弊端,一周學習的知識到了下周可能已經忘得差不多了,這樣做實驗勢必會影響實驗效率,或許是由於機房等其他因素的影響,但是如果能夠克服肯定會更能提高學習效率的!5、 課程收獲在學習過程中懂得了許多實用的操作方法,學會了刪除空行、空白段落、空白部分、刪除指定段落、全半形數字/字母的轉換、處理化學分子式、疊字查找、英文直引號替換為中文引號、處理奇偶段落、處理西文、中文和標點、電話號碼升位、手機號隱藏、移形換位、如何利用樣式快速地格式化文檔、如何讓企業的公文具備統一的格式、使用現有的模板創建文檔 、創建適合自己的模板、使用自建的模板創建新文檔、用其它模板改變現有文檔風格、製作長文檔的綱目結構、為長文檔設置多級標題編號、在文檔中讓插圖自動編號及交叉引用題注、為長文檔編制目錄和索引、預留裝訂線區域設置、設置節和頁眉頁腳 、添加不同類型的頁碼 、雙面列印設置、板書效果製作、動態顯示各區域市場銷售情況、路徑動畫製作、PPT特效動畫、製作內容豐富的幻燈片!雖然老師講解的比較深刻透徹,但是我掌握的還不是特別好,仍有部分內容比較模糊陌生,還需在課後多加練習!相信在這門課上學習到底知識在以後會經常用到的!課程描述

❼ 軟體工程專業學習心得

挺好的 不過剛開始工資待遇一般 慢慢來 可以上軟體英才網 上找找 望你找到好工作

與軟體工程經濟學課程總結相關的資料

熱點內容
蘇州假山景觀設計工程 瀏覽:862
哈爾濱工程造價招聘 瀏覽:937
建築工程土建勞務分包 瀏覽:632
道路監理工程師 瀏覽:476
安徽工程大學機電學院在本校嗎 瀏覽:370
河北工程大學保研率多少 瀏覽:287
有學質量工程師的書嗎 瀏覽:479
康樂縣建築工程公司 瀏覽:569
助理工程師二級 瀏覽:872
注冊安全工程師初級考試時間 瀏覽:901
食品科學與工程專業課題研究 瀏覽:881
工程造價圖紙建模 瀏覽:888
遼寧恆潤建設工程有限公司 瀏覽:93
實行施工總承包的工程項目 瀏覽:737
道路橋梁工程技術興趣愛好 瀏覽:316
密歇根理工大學電氣工程專業 瀏覽:388
廣西交通工程質量監督站 瀏覽:31
四川大學材料科學與工程學院考研參考書目 瀏覽:858
有線電視工程建設管理條例 瀏覽:270
雲南工程監理公司排名 瀏覽:673