關于軟件工程的總結五篇
關于軟件工程的總結五篇
篇一：軟件工程總結
摘要：
計算機是20世紀最重大的科學技巧成就之一，使當代社會的經濟、軍事、科研、教育、服務等方面在概念和技巧上發生了性的變化，對人類社會的進步已經并還將產生極為深刻的影響。目前，計算機是世界各發達國度劇烈競爭的科學技巧領域之一。
電子計算機早期功效主要是計算，后來已遠遠超越單純計算的功效，還可模擬、思維、進行自適應反饋處理等等，把它叫做“電腦”更為合實際。由于電子計算機功效的飛躍性發展，應用于生產和生活的各個方面，直接和顯著地提高了生產、工作和生活的效率、節奏和水平，在軟科學研究和應用中它也起著關鍵作用，因此它已被公認是現代技巧的神經中樞，是未來信息社會的心臟和錄魂。計算機學科分為四個領域，分別是計算機科學，計算機工程，軟件工程和信息系統。
正文：
軟件工程是研究和應用如何以系統性的、規范化的、可定量的過程化方法去開發和維護軟件，以及如何把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來的學科。包括項目管理，分析，設計，程序的編寫，測試和質量控制。它涉及到程序設計語言、數據庫、軟件開發工具、系統開發平臺、標準、設計模式等方面。
學了《軟件工程》這門課程和一些有關資料后，感覺一些東西都曾經接觸過，但在實際工作中有些理論要完全遵循可能還有些障礙，軟件工程只是提供了理論上的一些結論，但對項目的具體可操作性的規范的制定方面卻做的很少，《軟件工程》發展了幾十年，光是開發模型就達到了10多種，對不同的項目采用合適的開發模式，有些項目在不同的開發階段可能還要轉換開發模式，把它們靈活的應用到實際中還是很困難的。
軟件技術是信息技術產業的核心之一，軟件技術的發展是與信息技術產業的發展互相促進的。當今世界，信息技術正處于新一輪重大技術突破的前夜。預計今后 20~30 年是信息科學技術的變革突破期，可能導致 21 世紀下半葉一場新的信息技術革命。近年來，從 IT 界到一些國家首腦，都高度關注以物聯網為標志的新一輪信息技術的發展態勢，認為這是繼 20 世紀 80 年代 PC 機、90 年代互聯網、移動通信網之后，將引發 IT 業突破性發展的第三次 IT 產業化浪潮。每一次重大的技術變革都會引起企業間、產業間甚至國家間競爭格局的重大變化，也促進了軟件技術與軟件產業的重大變革與發展。
近年來，信息技術、軟件技術、軟件系統與軟件產業的發展備受關注，已有不少論述、分析與判斷。近 10 年內網絡技術經歷寬帶化、移動化和三網融合將走向基于 Ipv6 的下一代互聯網， 2010 年 1 月，國家 863 計劃信息技術領域辦公室和國家 863 計劃信息技術領域專家組，在上海舉辦“信息-物理融合系統 CPS發展戰略論壇”，提出“信息-物理融合系統 CPS 是一個綜合計算、網絡和物理環境的多維復雜系統，是信息和物理世界的深度的融合交互，可實現大型工程系統的實時感知、動態控制和信息服務，使系統更加可靠、高效與實時協同，使得人類物理現實和虛擬邏輯逐步融合，具有重要而廣泛的應用前景。 業界關于軟件工程的代表性觀點
1 創立與使用健全的工程原則，以便經濟地獲得可靠且高效率的軟件。
2 應用系統化，遵從原則，可被計量的方法來發展、操作及維護軟件；也就是把工程應用到軟件上。
3 與開發、管理及更新軟件產品有關的理論、方法及工具。
4 一種知識或學科，目標是生產品質良好、準時交貨、符合預算，滿足用戶所需的軟件。
5 實際應用科學知識在設計、建構電腦程序，與相伴而來所產生的文件，以及后續的操作和維護上。
6使用與系統化生產和維護軟件產品有關之技術與管理的知識，使軟件開發與修改可在有限的時間與費用下進行。
7建造由工程師團隊所開發之大型軟件系統有關的知識學科。
8 對軟件分析、設計、實施及維護的一種系統化方法。
9 系統化地應用工具和技術于開發以計算機為主的應用。
10軟件工程是關于設計和開發優質軟件。
《軟件工程》是一門綜合性和實踐性很強的核心課程，它屬于是一門交叉學科，包含有：軟件開發技術（軟件開發方法學、軟件開發過程、軟件工具和軟件工程環境 ）、軟件工程管理（軟件管理學、軟件經濟學、軟件心理學）。主要內容包括軟件工程概述、可行性分析、需求分析、概要設計、詳細設計、面向對象分析與設計、編碼、軟件測試、項目計劃與管理。
本課程是面向準備從事軟件開發的畢業生而開設的一門專業課程。針對計算機教學中軟件工程這一薄弱環結，結合目前軟件開發商對人才的要求，對計算機專業的畢業生進行軟件工程強化培訓，目的是使畢業生能夠了解和掌握軟件工程的基本理論和方法，并在實際軟件開發中運用這些方法。
我理解，軟件工程是按照工程學的管理方式，有組織、有計劃的，在一定的質量基礎、時間限度和成本范圍內，實現功能明確的軟件系統。而且，軟件工程在企業范圍內運行，一定需要企業資源的支持，要與企業的經營、決策、管理體系聯系在一起，才能夠被踏踏實實的落實下來。
軟件工程項目是一個需要一步一步的計算，分析思考而來的，需要不斷思考，研究不斷進步，軟件業作為一個服務業，要想得到發展，首先必須形成一個對軟件服務有迫切需要的市場。其次，這個市場中的消費者必須具備足夠的購買力。軟件的消費群體簡單一點，可以分為個體消費和企業消費。中國的企業群體，數量龐大，但是質量不高。上規模的企業極少。國內目前能夠形成比較大規模的獨立市場的，肯定是小規模的軟件系統。
隨著信息化時代的到來其地位越來越受到人們的重視，軟件工程從一個學科，或是某一個研究方向來說，人員僅僅是過程，方法的執行者，所以人員素質往往被忽略，軟件工程是一門實踐性很強的學科，所以在實際的軟件研究過程中，人員的素質占有很重要的地位。要有出色的軟件問世，研發人員的素質至關重要！
作為軟件工程的學習者應該不斷創新，不斷嘗試、實踐，不斷研究和學習，中國的軟件工程技術依舊滯后于國外一些軟件工程技術，作為新一代的學習者應該擔當起振興起中國軟件事業，使中國科技得到高速發展！
現在已經是信息化時代，信息化潮流不斷涌現，想要掌握主動權就是掌握信息化的發展方向，這就需要我們不斷學習，時間，研究，學習國外的先進技術，轉變自己的技術，然后融合，創新。
軟件技術不是一成不變的，是隨著社會的進步的不斷進步，不需要不斷的創新，不斷的改善的，需要我們不斷的學習，不斷的研究，不斷進步。
篇二：軟件工程工作總結與建議
姓名：
部門：行業開發部 – 超市項目組
出生日期：1980-11-25
個人簡介：
沒什么愛好，唯軟件開發技術情有獨鐘，常自娛自樂，自小熱愛編程，從小學6年級開始正式學習程序設計，至今已有12年有余，18歲中專畢業，參加工作，至今已有5年，近6年的軟件開發工作經驗，工作期間也不斷學習，完善自己的職業技能，理解軟件開發的思想，熟悉Delphi、C/C++/VC++、ASP、SQL Server、Html、腳本語言（如：VBScript、JavaScript），匯編，熟悉Win32SDK編程，經過多年的學習和實踐相結合對面象對象的設計與開發也有深刻的理解和自己獨特的見解。列寧曾說“實踐高于（理論的）認識，因為它不僅具有普遍性的品格，而且還具有直接現實性的品格。”，我始終相信。
對軟件逆向工程也比較熟悉,熟悉匯編/反匯編，熟悉各種靜態反編譯（反匯編）工具如DD、W32DASM、C32ASM等，熟悉各種動態跟蹤調試工具如SoftICE、OllyDBG等工具，熟悉加密與解密，能夠利用這些工具和我的知識對軟件進行加密，防止盜版，能夠對軟件進行解密和逆向工程，研究軟件的底層機理，屬于中國破解組織BCG/DFCG/OCN/DCM/CZG正式成員(注:這些組織都是以技術研究為主的,跟盜版是兩回事)。
同時熟悉多層系統的設計開發，熟悉各種軟件工具的使用，對Windows系列操作系統較為熟悉，對Linux操作系統有所了解。掌握面向對象的分析與設計和相關工具的使用，對軟件工程化也比較熟悉,由其感興趣的是敏捷軟件開發。曾任技術研發組組長，帶領技術研發組完成技術攻關，管理軟件項目。有極強的自學能力和歸納總結能力。對一項技術有強烈的鉆研欲望.
轉入正題了，首先談談，我認為我所在的項目組做得好的地方．在我們項目組中使用了CVS做軟件的版本控制，用RoboHelp寫文檔，用TestTrack做Bug跟蹤．
做得不好的地方就是需求描述不清晰，而我們過早的進入＂設計＂階段，過遲的進入測試階段．
我們需要的需求描述是這樣的：只說做什么，不說怎么做，并描述出希望得到的結果，至于操作習慣這些東西可以在得到了正確的軟件功能后再作調整．
例如：
再來看看我們的代碼：
我們目前的代碼根本不具備可測試性，當改動一個地方的時候我們不可能自己把所有代碼功能都跑１遍，以保證程序的正確性，保證程序的質量，有可能我們改動的這一個地方會牽扯到另一個地方或N個地方，而我們有可能沒有考慮到這個關聯性或沒有考慮完，于是１個地方的改動造成了N個地方的錯誤．這樣的問題在我們公司開發人員中基本是天天都在上演重復的一幕，造成開發成本／維護成本不斷的上升，產品遲遲不能穩定．
還有一個比較嚴重的問題是過早的進行設計，把程序的結構過早的定下來，這樣導致的后果是要當需求發生變化，目前的系統結構無法滿足需求時，可想而知后果的什么樣的．
再來說說測試：
我們的測試人員可說是做得比較好了的，這點我沒什么好說的．我只是想說讓我們開發產品應該盡早的提交給測試人員和用戶進行測試，這樣我們可以更早的得到反饋，對產品作出改進和修改．
我想重點對我們開發談談，提出一些自己的建議：
為了保證我們的程序具有可靠性，可維護性，可閱讀性，讓我們產品達到一個高質量的標準，我想唯一的方法就是讓我們代碼具有可測試性，可測試性的代碼是具有良好結構的，優美的，高質量的并且也是簡單的．其中以測試來驅動開發(TDD)的方法是我較為推崇的，我在家自己寫的程序基本都有Unit Test．
Unit Test又叫單元測試，是針對程序最基本結構單元所進行的測試。而TDD的過程是這樣的，寫一個測試程序，使其可以運行，重構。在寫這個測試程序的時候你考慮的不應該是基于什么結構單元，而是要考慮需要完成的什么功能。實現和重構的時候，具體是不是這個單元完成了這個功能依然不是你應該去考慮的，你考慮的還是——是不是完成了這個功能、是不是代碼真的清晰和可工作。你考慮的問題永遠是圍繞著具體的功能進行的，而不是圍繞某種結構進行的。你寫這個測試程序的時候，這個結構并不存在，并且今后也可能不存在（由于重構，你在別的結構部分實現了這個功能）。
明白這個道理就可以明白TDD實際還是基于需求驅動的，還是一種前瞻性的設計手段。只不過TDD讓這個需求更加具體，讓其前瞻性也更可以預測，并且在多種方法中給了你進行多種嘗試的機會。而當你認為這個測試只是單元測試的時候，無疑你就把程序的結構早早的做了一個固定，其是基于結構的而不是基于需求的，并且由于其基于結構的一面則設計的前瞻性很難得到保證，而就根本性的斷絕了你進行多種嘗試的可能。設計的前瞻性是指你的設計可以帶來可以預測的結果。而軟件的結構是動態的，并且隨著你必須進行的重構活動這樣的結構變更會日常性的存在。如果你的一個測試高度的依靠某種特殊的結構，在這樣的經常性重構的環境下，其被經常性修改的幾率會大大增加。而由于其結構的不確定性是根本不可能逆轉的，所以針對結構進行的測試根本不可能帶來結構上的可預測性，而談不上什么前瞻性了。
軟件開發是一個不斷跌代的過程，我們應該小步前進，不應該一開始就固定的程序的結構，一開始就使用復雜的設計模式，這些程序結構和設計模式都應該是我們通過了N次跌代后得到的結果．應該切忌為了顯示自己的水平而在一開始使用這些復雜的東西．
時間有限，就談到這里，附上兩篇我以前寫的關于開發的文章，作為參考，詳見附件 １．簡單設計
２．挑戰極限－測試驅動開發
篇三：軟件工程心得體會
對于學習軟件工程這門課程，我認為有許多東西要學習。其實在我看來學習這門課程的精髓是學習一種方法。是一個如何去分析和處理問題的過程，應該說其范疇已經遠遠不止局限于該門課程，成為了一個綜合的一個能夠解決問題的思想集合。讀完軟件工程案例教程這本書，我覺得自己受益匪淺。
整本書的內容邏輯很清晰明了，由淺入深循序漸進，首先我就大概描述下我們所學的內容，第一章是從整體分析軟件工程這門學科的發展和所處的社會環境，接著后面的幾章深入分析了軟件開放過程和模式、軟件項目管理、計算機工程、需求分析、結構化分析建模以及基于UML面向對象分析建模和測試等。 對于這本書我主要對需求分析和測試比較感興趣，在這我要著重的談一些自己的心得體會以及自己的看法。
一．需求分析
1.1需求分析的重要性
一款成功的軟件是建立在成功的需求分析之上的，而高質量的需求來源于用戶與開發人員之間有效的溝通與合作。當用戶有一個問題可以用計算機系統來解決，而開發人員開始幫助用戶解決這個問題，溝通就開始了。由此我們可以看出需求分析的重要性。
需求獲取可能是最困難、最關鍵、最易出錯及最需要溝通交流的活動。對需求的獲取往往有錯誤的認識：用戶知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問用戶系統的目標特征，什么是要完成的，什么樣的系統能適合商業需要就可以了，但是實際上需求獲取并不是想象的這樣簡單，這條溝通之路布滿了荊棘。首先需求獲取要定義問題范圍，系統的邊界往往是很難明確的，用戶不了解技術實現的細節，這樣造成了系統目標的混淆。
其次是對問題的理解，用戶對計算機系統的能力和限制缺乏了解，任何一個系統都會有很多的用戶或者不同類型的用戶，每個用戶只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說如何以一種精確的方式來描述需求，他們需要開發人員的協助和指導，但是用戶與開發人員之間的交流很容易出現障礙，忽略了那些被認為是"很明顯"的信息。最后是
需求的確認，因為需求的不穩定性往往隨著時間的推移產生變動，使之難以確認。為了克服以上的問題，必須有組織的執行需求的獲取活動。
1.2需求分析的原則
（1）需求分析必須能夠表達和理解問題的數據域和功能域。數據域包括數據流、數據內容和數據結構，而功能域反映上述 3 方面的控制信息。
（2）需求分析要把一個復雜問題按功能進行分解并逐層細化。通常，軟件系統要處理的問題如果太大、太復雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體的功能。在需求分析過程中，軟件系統的用戶需求中的數據、功能和行為都應細化。
（3）需求建模。模型可以幫助系統分析人員更好地理解軟件系統的數據、功能和行為，這些模型是軟件工程中下一階段進行系統設計的基礎。
1.3需求分析的注意事項
（1）確定詳細的需求，否則經費就算不準。經費估計錯誤的原因多為：用戶需求頻繁變動、遺漏重要需求、與用戶交流不夠、需求規格說明書質量低劣、需求分析不充分等。
（2）在編寫需求規格說明書之前，應明確要解決的問題。在試圖解決問題之前，要保證已考察了全部可替代的方案。要搞清哪地方有問題，真正的問題出在哪里。這樣，在編寫需求規格說明書時做到有的放矢，把存在的問題暴露出來。
（3）立即確定需求，并記錄下該需求的背景。沒有明確問題，就進行下一步的設計，想回避矛盾，可能會帶來更大的問題。用戶不確定需求，軟件設計人員自己決定需求，將會帶來嚴重的問題。為了避免將來可能出現的問題和軟件工程項目能夠盡快地進入到下一個階段的系統設計中，要盡可能迅速地把用戶需求確定下來。任何決定總比沒有決定要好。
（4）一旦在需求規格說明書中發現問題，立即改正。如果把存在的問題拖延到系統設計階段去改正，就可能要花數倍的時間和精力才能糾正同一錯誤。
（5）在眾多用戶需求中確定各個需求的優先順序，并確定可能存在的子集，以便為軟件設計、實施和項目管理等后續階段提供有利條件。
（6）需求分析時，不要進行系統設計的工作。需求分析的主要目的是確定軟件系統的外部特征，充分反映軟件系統應有的面貌，便于讓軟件設計人員根據
用戶需求，去全面地考慮軟件系統的體系結構、算法等。在需求分析階段要集中精力解決用戶需求存在的問題，盡可能避免產生遺留問題。
（7）對于復雜的軟件系統，要從多種視角進行需求分析。根據軟件系統的本質，切合實際地組織多種視角的需求。例如，可從根據用戶的類型，或根據響應的類型，或根據對象的軟件工程案例教程類型，或根據系統的模式等視角來組織用戶需求。通過多個視角來研究用戶需求問題，把可得到的不同的“投影”組合起來形成完整系統的描述。當試圖從整體觀點來描述軟件系統發生困難，或者有可能發生錯誤，或者很有可能遺失軟件系統的某些特性。而從不同的視角來 描述軟件系統，因為每個視角限制了研究的范圍并能夠將注意力集中于此，所以很容易保證所研究的問題是真正完整的。
（8）重視形式化方法，但不放棄自然語言。為了用戶需求表達的精確性和方便用戶的可理解性，一個好方法是把自然語言的表達與形式化規格說明并立，互相對照，而且在一般情況下，先用自然語言寫出，再給出它的形式模型。
（9）用戶需求中不應存在“待確定”的條款。如若有這種需要，應同時說明：何時由誰來解決該問題。
1.4用戶需求的類型
需求分析是從用戶最初的非形式化需求到滿足用戶要求的軟件產品的映射過程。它實際上是一個對用戶意圖不斷進行揭示和判斷的過程，其目的在于細化、精化軟件的作用范圍，確定擬開發軟件的功能和性能、約束、環境等。可將用戶的需求分為兩大類：功能性需求和非功能性需求。
（1）功能性需求。功能性需求主要說明了系統各功能部件與環境之間的相互作用的本質，即擬開發軟件在職能上實際應做到什么。一般來說，它是用戶最主要的需求，通常包括系統的輸入、系統能完成的功能、系統的輸出以及其他反應。在功能性需求中還應包括備選功能的定義識別。
（2）非功能性需求。非功能性要求主要從各個角度對所考慮的可能的解決方案起約束和限制作用。
1.5需求分析的方法
在軟件工程中，常用的需求分析方法有面向數據流的結構化分析方法（簡稱 SA）和面向對象的分析方法（簡稱 OOA）。此外，還有以用戶為中心的需求分析
方法。這些方法都采用圖文結合的方式，可以直觀地描述軟件的邏輯模型。這里僅介紹結構化分析方法和以用戶為中心的需求分析方法。
二.軟件測試
2.1軟件測試概述
軟件本身無形態，它是復雜的知識高度密集的邏輯產品，其中不可能沒有錯誤。軟件實施工程過程中必須伴隨著軟件質量保證的活動，而軟件測試是主要活動之一。在開發軟件的過程中，人們使用了許多保證軟件質量的方法分析、設計和實現軟件，但難免還會在工作中犯錯誤。這樣，在軟件產品中就會隱藏許多錯誤和缺陷。對于規模大、復雜性高的軟件更是如此。在這些錯誤中，有些是致命的錯誤，如果不排除，就會導致生命與財產的重大損失。
2.2軟件測試的目的
測試的目的是“說明程序能正確地執行應有的功能”，還是“表明程序沒有錯誤”？基于不同的立場，存在著兩種完全不同的測試目的。從用戶的角度出發，普遍希望通過軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產品。而從軟件開發者的角度出發，則希望測試成為表明軟件產品中不存在錯誤的過程，驗證該軟件已正確地實現了用戶的要求，確立人們對軟件質量的信心。因此，他們會選擇那些導致程效概率小的測試用例，回避那些易于暴露程序錯誤的測試用例。同時，也不會刻意去檢測、排除程序中可能包含的副作用。顯然，這樣的測試對完善和提高軟件質量毫無價值。因為在程序中往往存在著許多預料不到的問題，可能會被疏漏，許多隱藏的錯誤只有在特定的環境下才可能暴露出來。如果不把著眼點放在盡可能查找錯誤這樣一個基礎上，這些隱藏的錯誤和缺陷就查不出來，會遺留到運行階段中去。如果站在用戶的角度，替他們設想，就應當把測試活動的目標對準揭露程序中存在的錯誤。在選取測試用例時，考慮那些易于發現程序錯誤的數據。
2.3軟件測試的原則
（1）應當把“盡早地和不斷地進行軟件測試”作為軟件開發者的座右銘。由于原始問題的復雜性、軟件的復雜性和抽象性、軟件開發各個階段工作的多樣性，以及參加開發各種層次人員之間工作的配合關系等因素，使得開發的每個環節都可能產生錯誤。所以不應把軟件測試僅僅看成是軟件開發的一個獨立階段，
而應當把它貫穿到軟件開發的各個階段中。在需求分析階段就應該制訂測試計劃，以保證每個需求，每個設計單元都是可測試的，便于測試。堅持在軟件開發的各個階段的技術評審，這樣才能在開發過程中盡早發現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質量。
（2）測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。測試以前應當根據測試的要求，選擇在測試過程中使用的測試用例（Test Case）。測試用例主要用來檢驗程序員編制的程序，因此不但需要測試的輸入數據，而且需要針對這些輸入數據的預期輸出結果。如果對測試輸入數據沒有給出預期的程序輸出結果，那么就缺少了檢驗實測結果的基準，就有可能把一個似是而非的錯誤結果當成正確結果。
（3）程序員應避免檢查自己的程序。測試工作需要嚴格的作風、客觀的態度和冷靜的情緒。自己測試自己的軟件不容易發現錯誤，程序員應避免測試自己的程序。測試是一種“挑剔性”的行為，人們常常由于各種原因具有一種不愿否定自己工作的心理，認為揭露自己程序中的問題總不是一件愉快的事，這一心理狀態就成為測試自己程序的障礙。心理狀態和思維定式是測試自己程序的兩大障礙，應由別人或另外的機構來測試程序員編寫的程序。另外，程序員對軟件規格說明理解錯誤而引入的錯誤則更難發現。如果由別人來測試程序員編寫的程序，可能會更客觀、更有效，并更容易取得成功。要注意的是，這點不能與程序的調試（Debugging）互相混淆，調試由程序員自己來做可能更有效。
（4）在設計測試用例時，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問題變異的輸入條件。在測試程序時，人們常常傾向于過多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實上，軟件在投入運行以后，用戶的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶軟件工程案例教程 在鍵盤上按錯了鍵或打入了非法的命令。如果開發的軟件遇到這種情況時不能做出適當的反應，給出相應的信息，那么就容易產生故障，輕則給出錯誤的結果，重則導致軟件失效。因此，軟件系統處理非法命令的能力也必須在測試時受到檢驗。用不合理的輸件測試程序時，往往比用合理的輸入條件進行測試能發現更多
篇四：軟件工程實踐個人總結
在這個學期的軟件工程實踐課中，我們小組所選的題目為XXX公司全國銷售管理系統。按照這個題目及相關需求，我們小組對選題進行了需求分析、模塊設計、系統設計、數據庫設計、用戶界面設計等，并積極完成相應的開發編碼工作，后又對開發的系統進行了相應功能的測試工作。
對項目的理解
我們項目小組制作的的是XXX全國銷售管理系統，該公司考慮進行集約化經營模式，進軍電子商務領域，將全國市場資源進行整合形成有自身特色的經營體系，提升企業核心競爭能力，為此需要運用電子商務的力量對全國經銷商資源進行整合，對線上和線下進行雙重營銷。
經過對該項目的相關分析，我們小組明確了要具體實現的功能模塊。我們所開發的系統共有兩大模塊，一塊為XXX公司面向普通用戶的在線商城銷售系統；另一塊為XXX公司用戶進行對內的自我管理的管理系統。兩個大模塊下具體細分包括網上商城、客戶管理、市場及銷售管理、內部辦公系統、倉庫管理、財務管理、權限與安全7個子模塊
在線商城中，要實現商品信息的展示、瀏覽，用戶將添加商品到購物車，下單購買等功能。
管理系統中，要實現的功能包括：公司的內部人員及人員對應的權限的管理、公司產品庫存的管理、公司財務的管理、公司推出的一些市場營銷活動（比如：促銷、廣告等）的管理等。
自己在項目中負責的部分在小組完成該項目的工程中，組內進行了明確的分工，包括項目初期的分析、文檔撰寫及項目后期的開發測試過程。在小組中，我負責的部分為：項目初期的數據庫分析、數據庫設計文檔的撰寫和后期的測試工作。在數據庫設計及相應文檔撰寫方面，我獨立完成了數據庫的初期設計和數據庫設計文檔的撰寫，數據庫文檔總頁數為11頁。我所撰寫的數據庫設計文檔被組內其他人和其他文檔整合到一起，后來，實際的開發人員在此基礎上進行了一部分的修改。在后期的開發過程中，我負責的部分為系統測試。具體負責的部分為：網上商城、庫存管理、系統權限與安全這三個模塊的測試工作。
網上商城部分，主要功能包括商品信息的瀏覽、購物車功能及下訂單三大部分。
在編寫的測試用例中，包括：
1. 商品信息展示測試：分別以游客及網上商城注冊用戶身份瀏覽商城，在商品類目中選擇相應的商品信息，查看商品信息的顯示是否存在問題。隨機打開商品信息條目，查看商品的詳細描述信息，查看商品詳細信息頁面是否能正常顯示。
2. 購物車相關功能測試：購物車需要以注冊用戶身份登錄才能正
常使用，游客無法正常使用購物車功能。購物車相關功能包括商品添加到購物車、購物車中瀏覽已添加的商品、將已添加的商品從購物車中刪除、選擇購物車中的商品提交訂單。每個購物車的相關功能都編寫了相應的測試用例。結果發現在網上商城的初期版本中，購物車無法正常刪除已添加的商品信息，已作為bug提交給相應的開發人員。在后續的版本中，該bug已經被修復。
3. 由于訂單功能設計支付等相關部分，開發人員未完全實現訂單的相應功能。所以訂單部分無法進行詳細的測試。
庫存管理部分，主要功能包括商品庫存信息查看、出入庫單的查看、出入庫詳情的查看、商品出入庫及出入庫單的審批。
編寫的測試用例中，包括：
1. 商品庫存信息的查看：以超級管理員或庫存管理員的身份登錄后臺的管理系統，在庫存中查看商品的庫存詳細信息。
2. 出入庫單的查看：查看出入庫單是否正確。
3. 商品出入庫的測試：新建商品的出入庫單，提交知否能否在出入庫單中查看到且出入庫單的商品信息、數量、出入庫單的狀態是否正確。
4. 出入庫單的審批測試：在出入庫單的審批界面中，允許某些出入庫單的審批，不允許另一些出入庫單的審批，然后在出入庫單查看界面，查看審批的訂單的狀態是否發生改變。
系統角色權限及安全部分，主要的功能包括：新建角色、刪除角色、角色權限的管理。測試用例包括：
1. 以超級管理員用戶登錄后臺管理系統，建立新的角色并賦予相應的權限。
2. 以超級管理員身份登錄，并刪除某些已經存在的角色，看系統是否會產生某些級聯的錯誤。
3. 角色權限的管理：為已存在的角色添加或刪除某些權限。 經過測試，在我測試的模塊中，只發現商品購物車無法正常刪除已添加的商品，其他的功能都能正常使用。
經驗總結
本次的實踐讓我學到了一些我之前不了解的東西。這次的軟件工程實踐，分工十分明確，有分工的職責也很細，我分到的崗位是軟件測試。在此之前，對于軟件測試，我只是聽說過，卻并沒有真實地接觸過。對于組長指派給我的編寫測試用例，我完全不知道要怎么寫，也不知道從何下手。后來，同樣是負責測試用例的組里其他成員給我發了一份測試用例的文檔，我以此為參照，結合自己負責的部分，才漸漸對于測試用例有了一個大致的認識。按照自己對于軟件測試的理解，加上同學的測試用例示例，結合同學的指導，我才大致完成了測試用例文檔的編寫，也順利的完成了對開發的銷售管理系統的測試。 在這些測試用例的編寫中，由于我對軟件測試及測試用例的了解不深，難免存在一些問題，例如：不能很好的測試到系統中的一些功能，無法測試到一些會引發問題的情況等。
另外，在這次的軟件工程實踐里，也跟著整組人完整地經歷了一遍軟件開發的流程。之前的一些課程雖然也有涉及，但總的來說沒有這么完整，時間跨度上也沒有這么長。在這么課中，第一次接觸到了軟件開發小組中用到的周報，也學到了其他一些書本上沒有的東西。
篇五：軟件工程總結
軟件的概念
很多人對于軟件的理解并不準確，“軟件就是程序，軟件開發就是編程序”的這種錯誤觀點仍然存在。 軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關文檔的完整集合。 程序是按事先設計的功能和性能要求執行的指令序列。
數據是使程序能正常操縱信息的數據結構。
文檔是記錄軟件開發活動的階段性成果、理解軟件所必需的闡述性資料，如需求分析文檔、軟件設計文擋等 ，目的促進對軟件的開發,管理和維護；便于各種人員(用戶,開發人員)的交流。
軟件的分類
按照軟件的作用，一般可以將軟件做如下分類。
(1) 系統軟件
(2) 應用軟件
(3) 支撐軟件
(4) 可復用軟件
綜合上述，軟件具有復雜性和易變性。
什么是軟件工程
概括地說，軟件工程是指導計算機軟件開發和維護的工程學科。采用工程的概念、原理、技術和方法來開發與維護軟件，把經過時間考驗而證明正確的管理技術和當前能夠得到的最好的技術方法結合起來，以經濟地開發出高質量的軟件并有效地維護它，這就是軟件工程。
生存期的三個時期
軟件定義：弄清軟件“做什么” 軟件定義時期可以劃分成問題定義、可行性研究、需求分
析三個階段，其中，最核心的是需求分析階段，所以，軟件定義時期的工作也就是常說的系統分析。 軟件開發：集中解決軟件“怎樣做”概要設計、詳細設計、軟件實現和測試四個階段。
軟件維護：聚焦于軟件的“修改/完善”
瀑布模型
優點
可強迫開發人員采用規范化的方法。
嚴格地規定了每個階段必須提交的文檔。
要求每個階段交出的所有產品都必須是經過驗證的。
缺點
瀑布模型幾乎完全依賴于書面的規格說明，很可能導致最終開發出的軟件產品不能真正滿足用戶的需要。如果需求規格說明與用戶需求之間有差異，就會發生這種情況。
瀑布模型只適用于項目開始時需求已確定的情況。
適用場合：瀑布模型的適用于預先確定型系統（瀑布模型一般適用于功能、性能明確、完整、無重大變化的軟件系統的開發。例如操作系統、編譯系統、數據庫管理系統等系統軟件的開發。應用有一定的局限性。） 拋棄式原型模型特點
拋棄式原型模型建立原型的目的是，評價目標系統的某一個或某一些特性，以便更準確地確定需求，或者更嚴格地驗證設計方案。使用完之后就把該原型系統拋棄掉，然后再重新構造正式的目標系統。
拋棄式原型模型本質上仍屬于瀑布模型，建立原型系統只不過是“需求分析”和“有效性驗證”的一種輔
助手段，需求分析階段結束時原型系統的生存周期也就終止。
快速原型模型的特點、適用場合
特點：
用戶積極參與
原型的開發沒有嚴密的階段性
短期獲得測試版本，降低風險
適用場合：
需求含糊，用戶不能標識出詳細的輸入、處理和輸出需求
設計方案不明確，開發人員不能確定算法的有效性、操作系統的適應性或人機交互的有效性
增量模型的特點和適用場合
特點：
以功能遞增的方式進行軟件開發
能較快地產生可操作的系統
在每一步遞增中，都可以把用戶/開發者的經驗結合到不斷求精的產品中
可改善測試效果和降低軟件開發總成本
適用場合：
項目開始，明確了需求的大部分，但是需求可能會發生變化
對于市場和用戶把握不是很準，需要逐步了解
對于有龐大和復雜功能的系統進行功能改進，本身就需要一步一步實施的
螺旋模型的特點和適用場合
特點：
風險驅動，在生命周期早期就開始確定項目中存在的風險
需要開發人員具有相當豐富的風險評估經驗和專門知識
要求用戶參與階段評價，對用戶要求較高
適用場合：
單位內部開發的大規模軟件項目
風險是項目的主要制約因素
可能會發生重大變更
采用新技術
噴泉模型：主要用于面向對象技術的軟件開發項目，它克服了瀑布模型不支持軟件重用和多項開發活動集成的局限性，噴泉模型使開發過程具有迭代性和無間隙性。
噴泉模型以面向對象的軟件開發方法為基礎，以用戶需求作為噴泉模型的源泉，屬于面向對象的軟件過程模型。
結構化方法的基本思想：從系統功能出發，自頂向下，按照層次逐步分解求精
數據流圖 銀行儲蓄書P46—P48
結構化系統分析中加工邏輯說明的作用、三種表示形式及適用場合。（
結構化語言
判定表
判定樹
三種基本語句：
祈使語句
判斷語句
循環語句
結構化語言使用的三類詞匯：
祈使句中的動詞
數據字典中定義的名詞
某些邏輯表達式中的保留字
結構化和面向對象兩大方法的對比。
面向對象方法有如下優勢：
與人類思維方式一致
各階段過渡平滑
可維護性高、易于重用
生命力強
結構化方法：
容易理解和交流，對于大系統可以從全局逐步展開到局部，整體性較好。但工作費時過長，難以適應環境的急劇變化；對用戶需求的變更不能做出迅速的響應；維護工作繁重。
面向對象：
穩定可靠，有利于維護和重用，并容易實現多層分布式結構，技術先進，但對前期分析設計人員要求較高，用戶理解模型有困難。
C/S、B/S架構的特點、適用場合
C/S架構的缺點主要是部署、更新的問題。
B/S架構的缺點主要是受制于HTML的限制，無法像C/S那樣使用豐富的效果來展示數據，用戶體驗比較糟糕。
狀態圖
用例規格說明，會畫用例圖
圖書館系統用例圖
用例規格說明
用例名稱 借出圖書
參與者 圖書管理員（主要參與者），讀者（次要參與者）
假設 圖書館是開架借閱，讀者總是找到書后辦理借書手續，因此，借書不需要驗證 庫存，而且每本書都是可識別的。
前置條件 圖書管理員已被識別和授權
后置條件 存儲借書記錄，更新庫存數量，所借圖書狀態為出借
主事件流 1．圖書管理員將讀者借書卡提供給系統；
2．系統驗證讀者身份和借書條件；
3．圖書管理員將讀者所借圖書輸入系統；
4．系統記錄借書信息，并且修改圖書的狀態和此種書的可借數量；
5．系統累加讀者的借書數量；
6．重復3-5，直到圖書管理員確認全部圖書登記完畢；
7．系統打印借書清單，交易成功完成。
備選事件流 2a．非法讀者
1．系統提示讀者身份錯誤，用例結束
2b．讀者借書數已達限額
1．系統提示讀者已達結束限額，用例結束
2c．讀者有過期未還書籍
1．系統提示讀者應歸還的書籍列表和到期日，用例結束
5a．讀者借書數已達限額
1．系統提示，并要求結束輸入
2．圖書管理員確認借書完成
5b．讀者有該書的預定記錄
1. 刪除該書的預定信息
結構化設計要求模塊間的耦合程度盡可能小。
為此應：
用過程語句調用其他模塊
模塊間的參數作數據用
模塊間的參數盡可能少
總原則：盡量使用數據耦合，少用控制耦合，限制公共耦合的使用范圍，完全不用內容耦合。
結構化模塊詳細設計的建模工具
程序流程圖（程序框圖）
盒圖（NS圖）
PAD圖（問題分析圖）
程序設計語言（PDL）
面向對象方法的特點
對象、類、屬性和操作
封裝、隱藏
消息
繼承
多態
關系
UML的構架—4+1視圖中的具體內容。 略過
“購買商品”用例規格說明
參與者：出納員（主）、顧客
目標：完成一次商品銷售和支付
前置條件：管理員必須已經啟動系統，出納員必須已經登錄到這個系統
后置條件：銷售信息正確的記錄到系統中
觸發條件：顧客帶著所要購買的商品來到一個POS機終端
主事件流（主成功場景/基本路徑）：
出納員將每項商品的信息錄入系統
商品信息錄入完畢后，系統計算商品價格總額
出納員通知顧客商品總額
顧客支付現金，出納員確認收取現金
【軟件工程的總結】相關文章：
對老板總結感想總結二篇03-20
學科總結03-20
電場公式總結06-08
離校總結精選范文03-19
工會總結范本03-19
總結電熱的作用12-09
FLASH教程總結01-20
香茅做法總結03-19
工會總結精選范文03-20