關(guān)于軟件工程的總結五篇

關(guān)于軟件工程的總結五篇

　　篇一：軟件工程總結

　　摘要：

　　計算機是20世紀最重大的科學(xué)技巧成就之一，使當代社會(huì )的經(jīng)濟、軍事、科研、教育、服務(wù)等方面在概念和技巧上發(fā)生了性的變化，對人類(lèi)社會(huì )的進(jìn)步已經(jīng)并還將產(chǎn)生極為深刻的影響。目前，計算機是世界各發(fā)達國度劇烈競爭的科學(xué)技巧領(lǐng)域之一。

　　電子計算機早期功效主要是計算，后來(lái)已遠遠超越單純計算的功效，還可模擬、思維、進(jìn)行自適應反饋處理等等，把它叫做“電腦”更為合實(shí)際。由于電子計算機功效的飛躍性發(fā)展，應用于生產(chǎn)和生活的各個(gè)方面，直接和顯著(zhù)地提高了生產(chǎn)、工作和生活的效率、節奏和水平，在軟科學(xué)研究和應用中它也起著(zhù)關(guān)鍵作用，因此它已被公認是現代技巧的神經(jīng)中樞，是未來(lái)信息社會(huì )的心臟和錄魂。計算機學(xué)科分為四個(gè)領(lǐng)域，分別是計算機科學(xué)，計算機工程，軟件工程和信息系統。

　　正文：

　　軟件工程是研究和應用如何以系統性的、規范化的、可定量的過(guò)程化方法去開(kāi)發(fā)和維護軟件，以及如何把經(jīng)過(guò)時(shí)間考驗而證明正確的管理技術(shù)和當前能夠得到的最好的技術(shù)方法結合起來(lái)的學(xué)科。包括項目管理，分析，設計，程序的編寫(xiě)，測試和質(zhì)量控制。它涉及到程序設計語(yǔ)言、數據庫、軟件開(kāi)發(fā)工具、系統開(kāi)發(fā)平臺、標準、設計模式等方面。

　　學(xué)了《軟件工程》這門(mén)課程和一些有關(guān)資料后，感覺(jué)一些東西都曾經(jīng)接觸過(guò)，但在實(shí)際工作中有些理論要完全遵循可能還有些障礙，軟件工程只是提供了理論上的一些結論，但對項目的具體可操作性的規范的制定方面卻做的很少，《軟件工程》發(fā)展了幾十年，光是開(kāi)發(fā)模型就達到了10多種，對不同的項目采用合適的開(kāi)發(fā)模式，有些項目在不同的開(kāi)發(fā)階段可能還要轉換開(kāi)發(fā)模式，把它們靈活的應用到實(shí)際中還是很困難的。

　　軟件技術(shù)是信息技術(shù)產(chǎn)業(yè)的核心之一，軟件技術(shù)的發(fā)展是與信息技術(shù)產(chǎn)業(yè)的發(fā)展互相促進(jìn)的。當今世界，信息技術(shù)正處于新一輪重大技術(shù)突破的前夜。預計今后 20~30 年是信息科學(xué)技術(shù)的變革突破期，可能導致 21 世紀下半葉一場(chǎng)新的信息技術(shù)革命。近年來(lái)，從 IT 界到一些國家首腦，都高度關(guān)注以物聯(lián)網(wǎng)為標志的新一輪信息技術(shù)的發(fā)展態(tài)勢，認為這是繼 20 世紀 80 年代 PC 機、90 年代互聯(lián)網(wǎng)、移動(dòng)通信網(wǎng)之后，將引發(fā) IT 業(yè)突破性發(fā)展的第三次 IT 產(chǎn)業(yè)化浪潮。每一次重大的技術(shù)變革都會(huì )引起企業(yè)間、產(chǎn)業(yè)間甚至國家間競爭格局的重大變化，也促進(jìn)了軟件技術(shù)與軟件產(chǎn)業(yè)的重大變革與發(fā)展。

　　近年來(lái)，信息技術(shù)、軟件技術(shù)、軟件系統與軟件產(chǎn)業(yè)的發(fā)展備受關(guān)注，已有不少論述、分析與判斷。近 10 年內網(wǎng)絡(luò )技術(shù)經(jīng)歷寬帶化、移動(dòng)化和三網(wǎng)融合將走向基于 Ipv6 的下一代互聯(lián)網(wǎng)， 2010 年 1 月，國家 863 計劃信息技術(shù)領(lǐng)域辦公室和國家 863 計劃信息技術(shù)領(lǐng)域專(zhuān)家組，在上海舉辦“信息-物理融合系統 CPS發(fā)展戰略論壇”，提出“信息-物理融合系統 CPS 是一個(gè)綜合計算、網(wǎng)絡(luò )和物理環(huán)境的多維復雜系統，是信息和物理世界的深度的融合交互，可實(shí)現大型工程系統的實(shí)時(shí)感知、動(dòng)態(tài)控制和信息服務(wù)，使系統更加可靠、高效與實(shí)時(shí)協(xié)同，使得人類(lèi)物理現實(shí)和虛擬邏輯逐步融合，具有重要而廣泛的應用前景。 業(yè)界關(guān)于軟件工程的代表性觀(guān)點(diǎn)

　　1 創(chuàng )立與使用健全的工程原則，以便經(jīng)濟地獲得可靠且高效率的軟件。

　　2 應用系統化，遵從原則，可被計量的方法來(lái)發(fā)展、操作及維護軟件；也就是把工程應用到軟件上。

　　3 與開(kāi)發(fā)、管理及更新軟件產(chǎn)品有關(guān)的理論、方法及工具。

　　4 一種知識或學(xué)科，目標是生產(chǎn)品質(zhì)良好、準時(shí)交貨、符合預算，滿(mǎn)足用戶(hù)所需的軟件。

　　5 實(shí)際應用科學(xué)知識在設計、建構電腦程序，與相伴而來(lái)所產(chǎn)生的文件，以及后續的操作和維護上。

　　6使用與系統化生產(chǎn)和維護軟件產(chǎn)品有關(guān)之技術(shù)與管理的知識，使軟件開(kāi)發(fā)與修改可在有限的時(shí)間與費用下進(jìn)行。

　　7建造由工程師團隊所開(kāi)發(fā)之大型軟件系統有關(guān)的知識學(xué)科。

　　8 對軟件分析、設計、實(shí)施及維護的一種系統化方法。

　　9 系統化地應用工具和技術(shù)于開(kāi)發(fā)以計算機為主的應用。

　　10軟件工程是關(guān)于設計和開(kāi)發(fā)優(yōu)質(zhì)軟件。

　　《軟件工程》是一門(mén)綜合性和實(shí)踐性很強的核心課程，它屬于是一門(mén)交叉學(xué)科，包含有：軟件開(kāi)發(fā)技術(shù)（軟件開(kāi)發(fā)方法學(xué)、軟件開(kāi)發(fā)過(guò)程、軟件工具和軟件工程環(huán)境 ）、軟件工程管理（軟件管理學(xué)、軟件經(jīng)濟學(xué)、軟件心理學(xué)）。主要內容包括軟件工程概述、可行性分析、需求分析、概要設計、詳細設計、面向對象分析與設計、編碼、軟件測試、項目計劃與管理。

　　本課程是面向準備從事軟件開(kāi)發(fā)的畢業(yè)生而開(kāi)設的一門(mén)專(zhuān)業(yè)課程。針對計算機教學(xué)中軟件工程這一薄弱環(huán)結，結合目前軟件開(kāi)發(fā)商對人才的要求，對計算機專(zhuān)業(yè)的畢業(yè)生進(jìn)行軟件工程強化培訓，目的是使畢業(yè)生能夠了解和掌握軟件工程的基本理論和方法，并在實(shí)際軟件開(kāi)發(fā)中運用這些方法。

　　我理解，軟件工程是按照工程學(xué)的管理方式，有組織、有計劃的，在一定的質(zhì)量基礎、時(shí)間限度和成本范圍內，實(shí)現功能明確的軟件系統。而且，軟件工程在企業(yè)范圍內運行，一定需要企業(yè)資源的支持，要與企業(yè)的經(jīng)營(yíng)、決策、管理體系聯(lián)系在一起，才能夠被踏踏實(shí)實(shí)的落實(shí)下來(lái)。

　　軟件工程項目是一個(gè)需要一步一步的計算，分析思考而來(lái)的，需要不斷思考，研究不斷進(jìn)步，軟件業(yè)作為一個(gè)服務(wù)業(yè)，要想得到發(fā)展，首先必須形成一個(gè)對軟件服務(wù)有迫切需要的市場(chǎng)。其次，這個(gè)市場(chǎng)中的消費者必須具備足夠的購買(mǎi)力。軟件的消費群體簡(jiǎn)單一點(diǎn)，可以分為個(gè)體消費和企業(yè)消費。中國的企業(yè)群體，數量龐大，但是質(zhì)量不高。上規模的企業(yè)極少。國內目前能夠形成比較大規模的獨立市場(chǎng)的，肯定是小規模的軟件系統。

　　隨著(zhù)信息化時(shí)代的到來(lái)其地位越來(lái)越受到人們的重視，軟件工程從一個(gè)學(xué)科，或是某一個(gè)研究方向來(lái)說(shuō)，人員僅僅是過(guò)程，方法的執行者，所以人員素質(zhì)往往被忽略，軟件工程是一門(mén)實(shí)踐性很強的學(xué)科，所以在實(shí)際的軟件研究過(guò)程中，人員的素質(zhì)占有很重要的地位。要有出色的軟件問(wèn)世，研發(fā)人員的素質(zhì)至關(guān)重要！

　　作為軟件工程的學(xué)習者應該不斷創(chuàng )新，不斷嘗試、實(shí)踐，不斷研究和學(xué)習，中國的軟件工程技術(shù)依舊滯后于國外一些軟件工程技術(shù)，作為新一代的學(xué)習者應該擔當起振興起中國軟件事業(yè)，使中國科技得到高速發(fā)展！

　　現在已經(jīng)是信息化時(shí)代，信息化潮流不斷涌現，想要掌握主動(dòng)權就是掌握信息化的發(fā)展方向，這就需要我們不斷學(xué)習，時(shí)間，研究，學(xué)習國外的先進(jìn)技術(shù)，轉變自己的技術(shù)，然后融合，創(chuàng )新。

　　軟件技術(shù)不是一成不變的，是隨著(zhù)社會(huì )的進(jìn)步的不斷進(jìn)步，不需要不斷的創(chuàng )新，不斷的改善的，需要我們不斷的學(xué)習，不斷的研究，不斷進(jìn)步。

　　篇二：軟件工程工作總結與建議

　　姓名：

　　部門(mén)：行業(yè)開(kāi)發(fā)部 – 超市項目組

　　出生日期：1980-11-25

　　個(gè)人簡(jiǎn)介：

　　沒(méi)什么愛(ài)好，唯軟件開(kāi)發(fā)技術(shù)情有獨鐘，常自?shī)首詷?lè )，自小熱愛(ài)編程，從小學(xué)6年級開(kāi)始正式學(xué)習程序設計，至今已有12年有余，18歲中專(zhuān)畢業(yè)，參加工作，至今已有5年，近6年的軟件開(kāi)發(fā)工作經(jīng)驗，工作期間也不斷學(xué)習，完善自己的職業(yè)技能，理解軟件開(kāi)發(fā)的思想，熟悉Delphi、C/C++/VC++、ASP、SQL Server、Html、腳本語(yǔ)言（如：VBScript、JavaScript），匯編，熟悉Win32SDK編程，經(jīng)過(guò)多年的學(xué)習和實(shí)踐相結合對面象對象的設計與開(kāi)發(fā)也有深刻的理解和自己獨特的見(jiàn)解。列寧曾說(shuō)“實(shí)踐高于（理論的）認識，因為它不僅具有普遍性的品格，而且還具有直接現實(shí)性的品格�！�，我始終相信。

　　對軟件逆向工程也比較熟悉,熟悉匯編/反匯編，熟悉各種靜態(tài)反編譯（反匯編）工具如DD、W32DASM、C32ASM等，熟悉各種動(dòng)態(tài)跟蹤調試工具如SoftICE、OllyDBG等工具，熟悉加密與解密，能夠利用這些工具和我的知識對軟件進(jìn)行加密，防止盜版，能夠對軟件進(jìn)行解密和逆向工程，研究軟件的底層機理，屬于中國破解組織BCG/DFCG/OCN/DCM/CZG正式成員(注:這些組織都是以技術(shù)研究為主的,跟盜版是兩回事)。

　　同時(shí)熟悉多層系統的設計開(kāi)發(fā)，熟悉各種軟件工具的使用，對Windows系列操作系統較為熟悉，對Linux操作系統有所了解。掌握面向對象的分析與設計和相關(guān)工具的使用，對軟件工程化也比較熟悉,由其感興趣的是敏捷軟件開(kāi)發(fā)。曾任技術(shù)研發(fā)組組長(cháng)，帶領(lǐng)技術(shù)研發(fā)組完成技術(shù)攻關(guān)，管理軟件項目。有極強的自學(xué)能力和歸納總結能力。對一項技術(shù)有強烈的鉆研欲望.

　　轉入正題了，首先談?wù)�，我認為我所在的項目組做得好的地方．在我們項目組中使用了CVS做軟件的版本控制，用RoboHelp寫(xiě)文檔，用TestTrack做Bug跟蹤．

　　做得不好的地方就是需求描述不清晰，而我們過(guò)早的進(jìn)入＂設計＂階段，過(guò)遲的進(jìn)入測試階段．

　　我們需要的需求描述是這樣的：只說(shuō)做什么，不說(shuō)怎么做，并描述出希望得到的結果，至于操作習慣這些東西可以在得到了正確的軟件功能后再作調整．

　　例如：

　　再來(lái)看看我們的代碼：

　　我們目前的代碼根本不具備可測試性，當改動(dòng)一個(gè)地方的時(shí)候我們不可能自己把所有代碼功能都跑１遍，以保證程序的正確性，保證程序的質(zhì)量，有可能我們改動(dòng)的這一個(gè)地方會(huì )牽扯到另一個(gè)地方或N個(gè)地方，而我們有可能沒(méi)有考慮到這個(gè)關(guān)聯(lián)性或沒(méi)有考慮完，于是１個(gè)地方的改動(dòng)造成了N個(gè)地方的錯誤．這樣的問(wèn)題在我們公司開(kāi)發(fā)人員中基本是天天都在上演重復的一幕，造成開(kāi)發(fā)成本／維護成本不斷的上升，產(chǎn)品遲遲不能穩定．

　　還有一個(gè)比較嚴重的問(wèn)題是過(guò)早的進(jìn)行設計，把程序的結構過(guò)早的定下來(lái)，這樣導致的后果是要當需求發(fā)生變化，目前的系統結構無(wú)法滿(mǎn)足需求時(shí)，可想而知后果的什么樣的．

　　再來(lái)說(shuō)說(shuō)測試：

　　我們的測試人員可說(shuō)是做得比較好了的，這點(diǎn)我沒(méi)什么好說(shuō)的．我只是想說(shuō)讓我們開(kāi)發(fā)產(chǎn)品應該盡早的提交給測試人員和用戶(hù)進(jìn)行測試，這樣我們可以更早的得到反饋，對產(chǎn)品作出改進(jìn)和修改．

　　我想重點(diǎn)對我們開(kāi)發(fā)談?wù)�，提出一些自己的建議：

　　為了保證我們的程序具有可靠性，可維護性，可閱讀性，讓我們產(chǎn)品達到一個(gè)高質(zhì)量的標準，我想唯一的方法就是讓我們代碼具有可測試性，可測試性的代碼是具有良好結構的，優(yōu)美的，高質(zhì)量的并且也是簡(jiǎn)單的．其中以測試來(lái)驅動(dòng)開(kāi)發(fā)(TDD)的方法是我較為推崇的，我在家自己寫(xiě)的程序基本都有Unit Test．

　　Unit Test又叫單元測試，是針對程序最基本結構單元所進(jìn)行的測試。而TDD的過(guò)程是這樣的，寫(xiě)一個(gè)測試程序，使其可以運行，重構。在寫(xiě)這個(gè)測試程序的時(shí)候你考慮的不應該是基于什么結構單元，而是要考慮需要完成的什么功能。實(shí)現和重構的時(shí)候，具體是不是這個(gè)單元完成了這個(gè)功能依然不是你應該去考慮的，你考慮的還是——是不是完成了這個(gè)功能、是不是代碼真的清晰和可工作。你考慮的問(wèn)題永遠是圍繞著(zhù)具體的功能進(jìn)行的，而不是圍繞某種結構進(jìn)行的。你寫(xiě)這個(gè)測試程序的時(shí)候，這個(gè)結構并不存在，并且今后也可能不存在（由于重構，你在別的結構部分實(shí)現了這個(gè)功能）。

　　明白這個(gè)道理就可以明白TDD實(shí)際還是基于需求驅動(dòng)的，還是一種前瞻性的設計手段。只不過(guò)TDD讓這個(gè)需求更加具體，讓其前瞻性也更可以預測，并且在多種方法中給了你進(jìn)行多種嘗試的機會(huì )。而當你認為這個(gè)測試只是單元測試的時(shí)候，無(wú)疑你就把程序的結構早早的做了一個(gè)固定，其是基于結構的而不是基于需求的，并且由于其基于結構的一面則設計的前瞻性很難得到保證，而就根本性的斷絕了你進(jìn)行多種嘗試的可能。設計的前瞻性是指你的設計可以帶來(lái)可以預測的結果。而軟件的結構是動(dòng)態(tài)的，并且隨著(zhù)你必須進(jìn)行的重構活動(dòng)這樣的結構變更會(huì )日常性的存在。如果你的一個(gè)測試高度的依靠某種特殊的結構，在這樣的經(jīng)常性重構的環(huán)境下，其被經(jīng)常性修改的幾率會(huì )大大增加。而由于其結構的不確定性是根本不可能逆轉的，所以針對結構進(jìn)行的測試根本不可能帶來(lái)結構上的可預測性，而談不上什么前瞻性了。

　　軟件開(kāi)發(fā)是一個(gè)不斷跌代的過(guò)程，我們應該小步前進(jìn)，不應該一開(kāi)始就固定的程序的結構，一開(kāi)始就使用復雜的設計模式，這些程序結構和設計模式都應該是我們通過(guò)了N次跌代后得到的結果．應該切忌為了顯示自己的水平而在一開(kāi)始使用這些復雜的東西．

　　時(shí)間有限，就談到這里，附上兩篇我以前寫(xiě)的關(guān)于開(kāi)發(fā)的文章，作為參考，詳見(jiàn)附件 １．簡(jiǎn)單設計

　�。玻�挑戰極限－測試驅動(dòng)開(kāi)發(fā)

　　篇三：軟件工程心得體會(huì )

　　對于學(xué)習軟件工程這門(mén)課程，我認為有許多東西要學(xué)習。其實(shí)在我看來(lái)學(xué)習這門(mén)課程的精髓是學(xué)習一種方法。是一個(gè)如何去分析和處理問(wèn)題的過(guò)程，應該說(shuō)其范疇已經(jīng)遠遠不止局限于該門(mén)課程，成為了一個(gè)綜合的一個(gè)能夠解決問(wèn)題的思想集合。讀完軟件工程案例教程這本書(shū)，我覺(jué)得自己受益匪淺。

　　整本書(shū)的內容邏輯很清晰明了，由淺入深循序漸進(jìn)，首先我就大概描述下我們所學(xué)的內容，第一章是從整體分析軟件工程這門(mén)學(xué)科的發(fā)展和所處的社會(huì )環(huán)境，接著(zhù)后面的幾章深入分析了軟件開(kāi)放過(guò)程和模式、軟件項目管理、計算機工程、需求分析、結構化分析建模以及基于UML面向對象分析建模和測試等。 對于這本書(shū)我主要對需求分析和測試比較感興趣，在這我要著(zhù)重的談一些自己的心得體會(huì )以及自己的看法。

　　一．需求分析

　　1.1需求分析的重要性

　　一款成功的軟件是建立在成功的需求分析之上的，而高質(zhì)量的需求來(lái)源于用戶(hù)與開(kāi)發(fā)人員之間有效的溝通與合作。當用戶(hù)有一個(gè)問(wèn)題可以用計算機系統來(lái)解決，而開(kāi)發(fā)人員開(kāi)始幫助用戶(hù)解決這個(gè)問(wèn)題，溝通就開(kāi)始了。由此我們可以看出需求分析的重要性。

　　需求獲取可能是最困難、最關(guān)鍵、最易出錯及最需要溝通交流的活動(dòng)。對需求的獲取往往有錯誤的認識：用戶(hù)知道需求是什么，我們所要做的就是和他們交談從他們那里得到需求，只要問(wèn)用戶(hù)系統的目標特征，什么是要完成的，什么樣的系統能適合商業(yè)需要就可以了，但是實(shí)際上需求獲取并不是想象的這樣簡(jiǎn)單，這條溝通之路布滿(mǎn)了荊棘。首先需求獲取要定義問(wèn)題范圍，系統的邊界往往是很難明確的，用戶(hù)不了解技術(shù)實(shí)現的細節，這樣造成了系統目標的混淆。

　　其次是對問(wèn)題的理解，用戶(hù)對計算機系統的能力和限制缺乏了解，任何一個(gè)系統都會(huì )有很多的用戶(hù)或者不同類(lèi)型的用戶(hù)，每個(gè)用戶(hù)只知道自己需要的系統，而不知道系統的整體情況，他們不知道系統作為一個(gè)整體怎么樣工作效率更好，也不太清楚那些工作可以交給軟件完成，他們不清楚需求是什么，或者說(shuō)如何以一種精確的方式來(lái)描述需求，他們需要開(kāi)發(fā)人員的協(xié)助和指導，但是用戶(hù)與開(kāi)發(fā)人員之間的交流很容易出現障礙，忽略了那些被認為是"很明顯"的信息。最后是

　　需求的確認，因為需求的不穩定性往往隨著(zhù)時(shí)間的推移產(chǎn)生變動(dòng)，使之難以確認。為了克服以上的問(wèn)題，必須有組織的執行需求的獲取活動(dòng)。

　　1.2需求分析的原則

　�。�1）需求分析必須能夠表達和理解問(wèn)題的數據域和功能域。數據域包括數據流、數據內容和數據結構，而功能域反映上述 3 方面的控制信息。

　�。�2）需求分析要把一個(gè)復雜問(wèn)題按功能進(jìn)行分解并逐層細化。通常，軟件系統要處理的問(wèn)題如果太大、太復雜就很難理解，若劃分成幾部分，并確定各部分間的接口，就可完成整體的功能。在需求分析過(guò)程中，軟件系統的用戶(hù)需求中的數據、功能和行為都應細化。

　�。�3）需求建模。模型可以幫助系統分析人員更好地理解軟件系統的數據、功能和行為，這些模型是軟件工程中下一階段進(jìn)行系統設計的基礎。

　　1.3需求分析的注意事項

　�。�1）確定詳細的需求，否則經(jīng)費就算不準。經(jīng)費估計錯誤的原因多為：用戶(hù)需求頻繁變動(dòng)、遺漏重要需求、與用戶(hù)交流不夠、需求規格說(shuō)明書(shū)質(zhì)量低劣、需求分析不充分等。

　�。�2）在編寫(xiě)需求規格說(shuō)明書(shū)之前，應明確要解決的問(wèn)題。在試圖解決問(wèn)題之前，要保證已考察了全部可替代的方案。要搞清哪地方有問(wèn)題，真正的問(wèn)題出在哪里。這樣，在編寫(xiě)需求規格說(shuō)明書(shū)時(shí)做到有的放矢，把存在的問(wèn)題暴露出來(lái)。

　�。�3）立即確定需求，并記錄下該需求的背景。沒(méi)有明確問(wèn)題，就進(jìn)行下一步的設計，想回避矛盾，可能會(huì )帶來(lái)更大的問(wèn)題。用戶(hù)不確定需求，軟件設計人員自己決定需求，將會(huì )帶來(lái)嚴重的問(wèn)題。為了避免將來(lái)可能出現的問(wèn)題和軟件工程項目能夠盡快地進(jìn)入到下一個(gè)階段的系統設計中，要盡可能迅速地把用戶(hù)需求確定下來(lái)。任何決定總比沒(méi)有決定要好。

　�。�4）一旦在需求規格說(shuō)明書(shū)中發(fā)現問(wèn)題，立即改正。如果把存在的問(wèn)題拖延到系統設計階段去改正，就可能要花數倍的時(shí)間和精力才能糾正同一錯誤。

　�。�5）在眾多用戶(hù)需求中確定各個(gè)需求的優(yōu)先順序，并確定可能存在的子集，以便為軟件設計、實(shí)施和項目管理等后續階段提供有利條件。

　�。�6）需求分析時(shí)，不要進(jìn)行系統設計的工作。需求分析的主要目的是確定軟件系統的外部特征，充分反映軟件系統應有的面貌，便于讓軟件設計人員根據

　　用戶(hù)需求，去全面地考慮軟件系統的體系結構、算法等。在需求分析階段要集中精力解決用戶(hù)需求存在的問(wèn)題，盡可能避免產(chǎn)生遺留問(wèn)題。

　�。�7）對于復雜的軟件系統，要從多種視角進(jìn)行需求分析。根據軟件系統的本質(zhì)，切合實(shí)際地組織多種視角的需求。例如，可從根據用戶(hù)的類(lèi)型，或根據響應的類(lèi)型，或根據對象的軟件工程案例教程類(lèi)型，或根據系統的模式等視角來(lái)組織用戶(hù)需求。通過(guò)多個(gè)視角來(lái)研究用戶(hù)需求問(wèn)題，把可得到的不同的“投影”組合起來(lái)形成完整系統的描述。當試圖從整體觀(guān)點(diǎn)來(lái)描述軟件系統發(fā)生困難，或者有可能發(fā)生錯誤，或者很有可能遺失軟件系統的某些特性。而從不同的視角來(lái) 描述軟件系統，因為每個(gè)視角限制了研究的范圍并能夠將注意力集中于此，所以很容易保證所研究的問(wèn)題是真正完整的。

　�。�8）重視形式化方法，但不放棄自然語(yǔ)言。為了用戶(hù)需求表達的精確性和方便用戶(hù)的可理解性，一個(gè)好方法是把自然語(yǔ)言的表達與形式化規格說(shuō)明并立，互相對照，而且在一般情況下，先用自然語(yǔ)言寫(xiě)出，再給出它的形式模型。

　�。�9）用戶(hù)需求中不應存在“待確定”的條款。如若有這種需要，應同時(shí)說(shuō)明：何時(shí)由誰(shuí)來(lái)解決該問(wèn)題。

　　1.4用戶(hù)需求的類(lèi)型

　　需求分析是從用戶(hù)最初的非形式化需求到滿(mǎn)足用戶(hù)要求的軟件產(chǎn)品的映射過(guò)程。它實(shí)際上是一個(gè)對用戶(hù)意圖不斷進(jìn)行揭示和判斷的過(guò)程，其目的在于細化、精化軟件的作用范圍，確定擬開(kāi)發(fā)軟件的功能和性能、約束、環(huán)境等�？蓪⒂脩�(hù)的需求分為兩大類(lèi)：功能性需求和非功能性需求。

　�。�1）功能性需求。功能性需求主要說(shuō)明了系統各功能部件與環(huán)境之間的相互作用的本質(zhì)，即擬開(kāi)發(fā)軟件在職能上實(shí)際應做到什么。一般來(lái)說(shuō)，它是用戶(hù)最主要的需求，通常包括系統的輸入、系統能完成的功能、系統的輸出以及其他反應。在功能性需求中還應包括備選功能的定義識別。

　�。�2）非功能性需求。非功能性要求主要從各個(gè)角度對所考慮的可能的解決方案起約束和限制作用。

　　1.5需求分析的方法

　　在軟件工程中，常用的需求分析方法有面向數據流的結構化分析方法（簡(jiǎn)稱(chēng) SA）和面向對象的分析方法（簡(jiǎn)稱(chēng) OOA）。此外，還有以用戶(hù)為中心的需求分析

　　方法。這些方法都采用圖文結合的方式，可以直觀(guān)地描述軟件的邏輯模型。這里僅介紹結構化分析方法和以用戶(hù)為中心的需求分析方法。

　　二.軟件測試

　　2.1軟件測試概述

　　軟件本身無(wú)形態(tài)，它是復雜的知識高度密集的邏輯產(chǎn)品，其中不可能沒(méi)有錯誤。軟件實(shí)施工程過(guò)程中必須伴隨著(zhù)軟件質(zhì)量保證的活動(dòng)，而軟件測試是主要活動(dòng)之一。在開(kāi)發(fā)軟件的過(guò)程中，人們使用了許多保證軟件質(zhì)量的方法分析、設計和實(shí)現軟件，但難免還會(huì )在工作中犯錯誤。這樣，在軟件產(chǎn)品中就會(huì )隱藏許多錯誤和缺陷。對于規模大、復雜性高的軟件更是如此。在這些錯誤中，有些是致命的錯誤，如果不排除，就會(huì )導致生命與財產(chǎn)的重大損失。

　　2.2軟件測試的目的

　　測試的目的是“說(shuō)明程序能正確地執行應有的功能”，還是“表明程序沒(méi)有錯誤”？基于不同的立場(chǎng)，存在著(zhù)兩種完全不同的測試目的。從用戶(hù)的角度出發(fā)，普遍希望通過(guò)軟件測試暴露軟件中隱藏的錯誤和缺陷，以考慮是否可以接受該產(chǎn)品。而從軟件開(kāi)發(fā)者的角度出發(fā)，則希望測試成為表明軟件產(chǎn)品中不存在錯誤的過(guò)程，驗證該軟件已正確地實(shí)現了用戶(hù)的要求，確立人們對軟件質(zhì)量的信心。因此，他們會(huì )選擇那些導致程效概率小的測試用例，回避那些易于暴露程序錯誤的測試用例。同時(shí)，也不會(huì )刻意去檢測、排除程序中可能包含的副作用。顯然，這樣的測試對完善和提高軟件質(zhì)量毫無(wú)價(jià)值。因為在程序中往往存在著(zhù)許多預料不到的問(wèn)題，可能會(huì )被疏漏，許多隱藏的錯誤只有在特定的環(huán)境下才可能暴露出來(lái)。如果不把著(zhù)眼點(diǎn)放在盡可能查找錯誤這樣一個(gè)基礎上，這些隱藏的錯誤和缺陷就查不出來(lái)，會(huì )遺留到運行階段中去。如果站在用戶(hù)的角度，替他們設想，就應當把測試活動(dòng)的目標對準揭露程序中存在的錯誤。在選取測試用例時(shí)，考慮那些易于發(fā)現程序錯誤的數據。

　　2.3軟件測試的原則

　�。�1）應當把“盡早地和不斷地進(jìn)行軟件測試”作為軟件開(kāi)發(fā)者的座右銘。由于原始問(wèn)題的復雜性、軟件的復雜性和抽象性、軟件開(kāi)發(fā)各個(gè)階段工作的多樣性，以及參加開(kāi)發(fā)各種層次人員之間工作的配合關(guān)系等因素，使得開(kāi)發(fā)的每個(gè)環(huán)節都可能產(chǎn)生錯誤。所以不應把軟件測試僅僅看成是軟件開(kāi)發(fā)的一個(gè)獨立階段，

　　而應當把它貫穿到軟件開(kāi)發(fā)的各個(gè)階段中。在需求分析階段就應該制訂測試計劃，以保證每個(gè)需求，每個(gè)設計單元都是可測試的，便于測試。堅持在軟件開(kāi)發(fā)的各個(gè)階段的技術(shù)評審，這樣才能在開(kāi)發(fā)過(guò)程中盡早發(fā)現和預防錯誤，把出現的錯誤克服在早期，杜絕某些隱患，提高軟件質(zhì)量。

　�。�2）測試用例應由測試輸入數據和與之對應的預期輸出結果這兩部分組成。測試以前應當根據測試的要求，選擇在測試過(guò)程中使用的測試用例（Test Case）。測試用例主要用來(lái)檢驗程序員編制的程序，因此不但需要測試的輸入數據，而且需要針對這些輸入數據的預期輸出結果。如果對測試輸入數據沒(méi)有給出預期的程序輸出結果，那么就缺少了檢驗實(shí)測結果的基準，就有可能把一個(gè)似是而非的錯誤結果當成正確結果。

　�。�3）程序員應避免檢查自己的程序。測試工作需要嚴格的作風(fēng)、客觀(guān)的態(tài)度和冷靜的情緒。自己測試自己的軟件不容易發(fā)現錯誤，程序員應避免測試自己的程序。測試是一種“挑剔性”的行為，人們常常由于各種原因具有一種不愿否定自己工作的心理，認為揭露自己程序中的問(wèn)題總不是一件愉快的事，這一心理狀態(tài)就成為測試自己程序的障礙。心理狀態(tài)和思維定式是測試自己程序的兩大障礙，應由別人或另外的機構來(lái)測試程序員編寫(xiě)的程序。另外，程序員對軟件規格說(shuō)明理解錯誤而引入的錯誤則更難發(fā)現。如果由別人來(lái)測試程序員編寫(xiě)的程序，可能會(huì )更客觀(guān)、更有效，并更容易取得成功。要注意的是，這點(diǎn)不能與程序的調試（Debugging）互相混淆，調試由程序員自己來(lái)做可能更有效。

　�。�4）在設計測試用例時(shí)，應當包括合理的輸入條件和不合理的輸入條件。合理的輸入條件是指能驗證程序正確的輸入條件，而不合理的輸入條件是指異常的、臨界的、可能引起問(wèn)題變異的輸入條件。在測試程序時(shí)，人們常常傾向于過(guò)多地考慮合法的和期望的輸入條件，以檢查程序是否做了它應該做的事情，而忽視了不合法的和預想不到的輸入條件。事實(shí)上，軟件在投入運行以后，用戶(hù)的使用往往不遵循事先的約定，使用了一些意外的輸入，如用戶(hù)軟件工程案例教程 在鍵盤(pán)上按錯了鍵或打入了非法的命令。如果開(kāi)發(fā)的軟件遇到這種情況時(shí)不能做出適當的反應，給出相應的信息，那么就容易產(chǎn)生故障，輕則給出錯誤的結果，重則導致軟件失效。因此，軟件系統處理非法命令的能力也必須在測試時(shí)受到檢驗。用不合理的輸件測試程序時(shí)，往往比用合理的輸入條件進(jìn)行測試能發(fā)現更多

　　篇四：軟件工程實(shí)踐個(gè)人總結

　　在這個(gè)學(xué)期的軟件工程實(shí)踐課中，我們小組所選的題目為XXX公司全國銷(xiāo)售管理系統。按照這個(gè)題目及相關(guān)需求，我們小組對選題進(jìn)行了需求分析、模塊設計、系統設計、數據庫設計、用戶(hù)界面設計等，并積極完成相應的開(kāi)發(fā)編碼工作，后又對開(kāi)發(fā)的系統進(jìn)行了相應功能的測試工作。

　　對項目的理解

　　我們項目小組制作的的是XXX全國銷(xiāo)售管理系統，該公司考慮進(jìn)行集約化經(jīng)營(yíng)模式，進(jìn)軍電子商務(wù)領(lǐng)域，將全國市場(chǎng)資源進(jìn)行整合形成有自身特色的經(jīng)營(yíng)體系，提升企業(yè)核心競爭能力，為此需要運用電子商務(wù)的力量對全國經(jīng)銷(xiāo)商資源進(jìn)行整合，對線(xiàn)上和線(xiàn)下進(jìn)行雙重營(yíng)銷(xiāo)。

　　經(jīng)過(guò)對該項目的相關(guān)分析，我們小組明確了要具體實(shí)現的功能模塊。我們所開(kāi)發(fā)的系統共有兩大模塊，一塊為XXX公司面向普通用戶(hù)的在線(xiàn)商城銷(xiāo)售系統；另一塊為XXX公司用戶(hù)進(jìn)行對內的自我管理的管理系統。兩個(gè)大模塊下具體細分包括網(wǎng)上商城、客戶(hù)管理、市場(chǎng)及銷(xiāo)售管理、內部辦公系統、倉庫管理、財務(wù)管理、權限與安全7個(gè)子模塊

　　在線(xiàn)商城中，要實(shí)現商品信息的展示、瀏覽，用戶(hù)將添加商品到購物車(chē)，下單購買(mǎi)等功能。

　　管理系統中，要實(shí)現的功能包括：公司的內部人員及人員對應的權限的管理、公司產(chǎn)品庫存的管理、公司財務(wù)的管理、公司推出的一些市場(chǎng)營(yíng)銷(xiāo)活動(dòng)（比如：促銷(xiāo)、廣告等）的管理等。

　　自己在項目中負責的部分在小組完成該項目的工程中，組內進(jìn)行了明確的分工，包括項目初期的分析、文檔撰寫(xiě)及項目后期的開(kāi)發(fā)測試過(guò)程。在小組中，我負責的部分為：項目初期的數據庫分析、數據庫設計文檔的撰寫(xiě)和后期的測試工作。在數據庫設計及相應文檔撰寫(xiě)方面，我獨立完成了數據庫的初期設計和數據庫設計文檔的撰寫(xiě)，數據庫文檔總頁(yè)數為11頁(yè)。我所撰寫(xiě)的數據庫設計文檔被組內其他人和其他文檔整合到一起，后來(lái)，實(shí)際的開(kāi)發(fā)人員在此基礎上進(jìn)行了一部分的修改。在后期的開(kāi)發(fā)過(guò)程中，我負責的部分為系統測試。具體負責的部分為：網(wǎng)上商城、庫存管理、系統權限與安全這三個(gè)模塊的測試工作。

　　網(wǎng)上商城部分，主要功能包括商品信息的瀏覽、購物車(chē)功能及下訂單三大部分。

　　在編寫(xiě)的測試用例中，包括：

　　1. 商品信息展示測試：分別以游客及網(wǎng)上商城注冊用戶(hù)身份瀏覽商城，在商品類(lèi)目中選擇相應的商品信息，查看商品信息的顯示是否存在問(wèn)題。隨機打開(kāi)商品信息條目，查看商品的詳細描述信息，查看商品詳細信息頁(yè)面是否能正常顯示。

　　2. 購物車(chē)相關(guān)功能測試：購物車(chē)需要以注冊用戶(hù)身份登錄才能正

　　常使用，游客無(wú)法正常使用購物車(chē)功能。購物車(chē)相關(guān)功能包括商品添加到購物車(chē)、購物車(chē)中瀏覽已添加的商品、將已添加的商品從購物車(chē)中刪除、選擇購物車(chē)中的商品提交訂單。每個(gè)購物車(chē)的相關(guān)功能都編寫(xiě)了相應的測試用例。結果發(fā)現在網(wǎng)上商城的初期版本中，購物車(chē)無(wú)法正常刪除已添加的商品信息，已作為bug提交給相應的開(kāi)發(fā)人員。在后續的版本中，該bug已經(jīng)被修復。

　　3. 由于訂單功能設計支付等相關(guān)部分，開(kāi)發(fā)人員未完全實(shí)現訂單的相應功能。所以訂單部分無(wú)法進(jìn)行詳細的測試。

　　庫存管理部分，主要功能包括商品庫存信息查看、出入庫單的查看、出入庫詳情的查看、商品出入庫及出入庫單的審批。

　　編寫(xiě)的測試用例中，包括：

　　1. 商品庫存信息的查看：以超級管理員或庫存管理員的身份登錄后臺的管理系統，在庫存中查看商品的庫存詳細信息。

　　2. 出入庫單的查看：查看出入庫單是否正確。

　　3. 商品出入庫的測試：新建商品的出入庫單，提交知否能否在出入庫單中查看到且出入庫單的商品信息、數量、出入庫單的狀態(tài)是否正確。

　　4. 出入庫單的審批測試：在出入庫單的審批界面中，允許某些出入庫單的審批，不允許另一些出入庫單的審批，然后在出入庫單查看界面，查看審批的訂單的狀態(tài)是否發(fā)生改變。

　　系統角色權限及安全部分，主要的功能包括：新建角色、刪除角色、角色權限的管理。測試用例包括：

　　1. 以超級管理員用戶(hù)登錄后臺管理系統，建立新的角色并賦予相應的權限。

　　2. 以超級管理員身份登錄，并刪除某些已經(jīng)存在的角色，看系統是否會(huì )產(chǎn)生某些級聯(lián)的錯誤。

　　3. 角色權限的管理：為已存在的角色添加或刪除某些權限。 經(jīng)過(guò)測試，在我測試的模塊中，只發(fā)現商品購物車(chē)無(wú)法正常刪除已添加的商品，其他的功能都能正常使用。

　　經(jīng)驗總結

　　本次的實(shí)踐讓我學(xué)到了一些我之前不了解的東西。這次的軟件工程實(shí)踐，分工十分明確，有分工的職責也很細，我分到的崗位是軟件測試。在此之前，對于軟件測試，我只是聽(tīng)說(shuō)過(guò)，卻并沒(méi)有真實(shí)地接觸過(guò)。對于組長(cháng)指派給我的編寫(xiě)測試用例，我完全不知道要怎么寫(xiě)，也不知道從何下手。后來(lái)，同樣是負責測試用例的組里其他成員給我發(fā)了一份測試用例的文檔，我以此為參照，結合自己負責的部分，才漸漸對于測試用例有了一個(gè)大致的認識。按照自己對于軟件測試的理解，加上同學(xué)的測試用例示例，結合同學(xué)的指導，我才大致完成了測試用例文檔的編寫(xiě)，也順利的完成了對開(kāi)發(fā)的銷(xiāo)售管理系統的測試。 在這些測試用例的編寫(xiě)中，由于我對軟件測試及測試用例的了解不深，難免存在一些問(wèn)題，例如：不能很好的測試到系統中的一些功能，無(wú)法測試到一些會(huì )引發(fā)問(wèn)題的情況等。

　　另外，在這次的軟件工程實(shí)踐里，也跟著(zhù)整組人完整地經(jīng)歷了一遍軟件開(kāi)發(fā)的流程。之前的一些課程雖然也有涉及，但總的來(lái)說(shuō)沒(méi)有這么完整，時(shí)間跨度上也沒(méi)有這么長(cháng)。在這么課中，第一次接觸到了軟件開(kāi)發(fā)小組中用到的周報，也學(xué)到了其他一些書(shū)本上沒(méi)有的東西。

　　篇五：軟件工程總結

　　軟件的概念

　　很多人對于軟件的理解并不準確，“軟件就是程序，軟件開(kāi)發(fā)就是編程序”的這種錯誤觀(guān)點(diǎn)仍然存在。 軟件是計算機系統中與硬件相互依存的另一部分，它是包括程序，數據及其相關(guān)文檔的完整集合。 程序是按事先設計的功能和性能要求執行的指令序列。

　　數據是使程序能正常操縱信息的數據結構。

　　文檔是記錄軟件開(kāi)發(fā)活動(dòng)的階段性成果、理解軟件所必需的闡述性資料，如需求分析文檔、軟件設計文擋等 ，目的促進(jìn)對軟件的開(kāi)發(fā),管理和維護；便于各種人員(用戶(hù),開(kāi)發(fā)人員)的交流。

　　軟件的分類(lèi)

　　按照軟件的作用，一般可以將軟件做如下分類(lèi)。

　　(1) 系統軟件

　　(2) 應用軟件

　　(3) 支撐軟件

　　(4) 可復用軟件

　　綜合上述，軟件具有復雜性和易變性。

　　什么是軟件工程

　　概括地說(shuō)，軟件工程是指導計算機軟件開(kāi)發(fā)和維護的工程學(xué)科。采用工程的概念、原理、技術(shù)和方法來(lái)開(kāi)發(fā)與維護軟件，把經(jīng)過(guò)時(shí)間考驗而證明正確的管理技術(shù)和當前能夠得到的最好的技術(shù)方法結合起來(lái)，以經(jīng)濟地開(kāi)發(fā)出高質(zhì)量的軟件并有效地維護它，這就是軟件工程。

　　生存期的三個(gè)時(shí)期

　　軟件定義：弄清軟件“做什么” 軟件定義時(shí)期可以劃分成問(wèn)題定義、可行性研究、需求分

　　析三個(gè)階段，其中，最核心的是需求分析階段，所以，軟件定義時(shí)期的工作也就是常說(shuō)的系統分析。 軟件開(kāi)發(fā)：集中解決軟件“怎樣做”概要設計、詳細設計、軟件實(shí)現和測試四個(gè)階段。

　　軟件維護：聚焦于軟件的“修改/完善”

　　瀑布模型

　　優(yōu)點(diǎn)

　　可強迫開(kāi)發(fā)人員采用規范化的方法。

　　嚴格地規定了每個(gè)階段必須提交的文檔。

　　要求每個(gè)階段交出的所有產(chǎn)品都必須是經(jīng)過(guò)驗證的。

　　缺點(diǎn)

　　瀑布模型幾乎完全依賴(lài)于書(shū)面的規格說(shuō)明，很可能導致最終開(kāi)發(fā)出的軟件產(chǎn)品不能真正滿(mǎn)足用戶(hù)的需要。如果需求規格說(shuō)明與用戶(hù)需求之間有差異，就會(huì )發(fā)生這種情況。

　　瀑布模型只適用于項目開(kāi)始時(shí)需求已確定的情況。

　　適用場(chǎng)合：瀑布模型的適用于預先確定型系統（瀑布模型一般適用于功能、性能明確、完整、無(wú)重大變化的軟件系統的開(kāi)發(fā)。例如操作系統、編譯系統、數據庫管理系統等系統軟件的開(kāi)發(fā)。應用有一定的局限性。） 拋棄式原型模型特點(diǎn)

　　拋棄式原型模型建立原型的目的是，評價(jià)目標系統的某一個(gè)或某一些特性，以便更準確地確定需求，或者更嚴格地驗證設計方案。使用完之后就把該原型系統拋棄掉，然后再重新構造正式的目標系統。

　　拋棄式原型模型本質(zhì)上仍屬于瀑布模型，建立原型系統只不過(guò)是“需求分析”和“有效性驗證”的一種輔

　　助手段，需求分析階段結束時(shí)原型系統的生存周期也就終止。

　　快速原型模型的特點(diǎn)、適用場(chǎng)合

　　特點(diǎn)：

　　用戶(hù)積極參與

　　原型的開(kāi)發(fā)沒(méi)有嚴密的階段性

　　短期獲得測試版本，降低風(fēng)險

　　適用場(chǎng)合：

　　需求含糊，用戶(hù)不能標識出詳細的輸入、處理和輸出需求

　　設計方案不明確，開(kāi)發(fā)人員不能確定算法的有效性、操作系統的適應性或人機交互的有效性

　　增量模型的特點(diǎn)和適用場(chǎng)合

　　特點(diǎn)：

　　以功能遞增的方式進(jìn)行軟件開(kāi)發(fā)

　　能較快地產(chǎn)生可操作的系統

　　在每一步遞增中，都可以把用戶(hù)/開(kāi)發(fā)者的經(jīng)驗結合到不斷求精的產(chǎn)品中

　　可改善測試效果和降低軟件開(kāi)發(fā)總成本

　　適用場(chǎng)合：

　　項目開(kāi)始，明確了需求的大部分，但是需求可能會(huì )發(fā)生變化

　　對于市場(chǎng)和用戶(hù)把握不是很準，需要逐步了解

　　對于有龐大和復雜功能的系統進(jìn)行功能改進(jìn)，本身就需要一步一步實(shí)施的

　　螺旋模型的特點(diǎn)和適用場(chǎng)合

　　特點(diǎn)：

　　風(fēng)險驅動(dòng)，在生命周期早期就開(kāi)始確定項目中存在的風(fēng)險

　　需要開(kāi)發(fā)人員具有相當豐富的風(fēng)險評估經(jīng)驗和專(zhuān)門(mén)知識

　　要求用戶(hù)參與階段評價(jià)，對用戶(hù)要求較高

　　適用場(chǎng)合：

　　單位內部開(kāi)發(fā)的大規模軟件項目

　　風(fēng)險是項目的主要制約因素

　　可能會(huì )發(fā)生重大變更

　　采用新技術(shù)

　　噴泉模型：主要用于面向對象技術(shù)的軟件開(kāi)發(fā)項目，它克服了瀑布模型不支持軟件重用和多項開(kāi)發(fā)活動(dòng)集成的局限性，噴泉模型使開(kāi)發(fā)過(guò)程具有迭代性和無(wú)間隙性。

　　噴泉模型以面向對象的軟件開(kāi)發(fā)方法為基礎，以用戶(hù)需求作為噴泉模型的源泉，屬于面向對象的軟件過(guò)程模型。

　　結構化方法的基本思想：從系統功能出發(fā)，自頂向下，按照層次逐步分解求精

　　數據流圖 銀行儲蓄書(shū)P46—P48

　　結構化系統分析中加工邏輯說(shuō)明的作用、三種表示形式及適用場(chǎng)合。（

　　結構化語(yǔ)言

　　判定表

　　判定樹(shù)

　　三種基本語(yǔ)句：

　　祈使語(yǔ)句

　　判斷語(yǔ)句

　　循環(huán)語(yǔ)句

　　結構化語(yǔ)言使用的三類(lèi)詞匯：

　　祈使句中的動(dòng)詞

　　數據字典中定義的名詞

　　某些邏輯表達式中的保留字

　　結構化和面向對象兩大方法的對比。

　　面向對象方法有如下優(yōu)勢：

　　與人類(lèi)思維方式一致

　　各階段過(guò)渡平滑

　　可維護性高、易于重用

　　生命力強

　　結構化方法：

　　容易理解和交流，對于大系統可以從全局逐步展開(kāi)到局部，整體性較好。但工作費時(shí)過(guò)長(cháng)，難以適應環(huán)境的急劇變化；對用戶(hù)需求的變更不能做出迅速的響應；維護工作繁重。

　　面向對象：

　　穩定可靠，有利于維護和重用，并容易實(shí)現多層分布式結構，技術(shù)先進(jìn)，但對前期分析設計人員要求較高，用戶(hù)理解模型有困難。

　　C/S、B/S架構的特點(diǎn)、適用場(chǎng)合

　　C/S架構的缺點(diǎn)主要是部署、更新的問(wèn)題。

　　B/S架構的缺點(diǎn)主要是受制于HTML的限制，無(wú)法像C/S那樣使用豐富的效果來(lái)展示數據，用戶(hù)體驗比較糟糕。

　　狀態(tài)圖

　　用例規格說(shuō)明，會(huì )畫(huà)用例圖

　　圖書(shū)館系統用例圖

　　用例規格說(shuō)明

　　用例名稱(chēng) 借出圖書(shū)

　　參與者 圖書(shū)管理員（主要參與者），讀者（次要參與者）

　　假設 圖書(shū)館是開(kāi)架借閱，讀者總是找到書(shū)后辦理借書(shū)手續，因此，借書(shū)不需要驗證 庫存，而且每本書(shū)都是可識別的。

　　前置條件 圖書(shū)管理員已被識別和授權

　　后置條件 存儲借書(shū)記錄，更新庫存數量，所借圖書(shū)狀態(tài)為出借

　　主事件流 1．圖書(shū)管理員將讀者借書(shū)卡提供給系統；

　　2．系統驗證讀者身份和借書(shū)條件；

　　3．圖書(shū)管理員將讀者所借圖書(shū)輸入系統；

　　4．系統記錄借書(shū)信息，并且修改圖書(shū)的狀態(tài)和此種書(shū)的可借數量；

　　5．系統累加讀者的借書(shū)數量；

　　6．重復3-5，直到圖書(shū)管理員確認全部圖書(shū)登記完畢；

　　7．系統打印借書(shū)清單，交易成功完成。

　　備選事件流 2a．非法讀者

　　1．系統提示讀者身份錯誤，用例結束

　　2b．讀者借書(shū)數已達限額

　　1．系統提示讀者已達結束限額，用例結束

　　2c．讀者有過(guò)期未還書(shū)籍

　　1．系統提示讀者應歸還的書(shū)籍列表和到期日，用例結束

　　5a．讀者借書(shū)數已達限額

　　1．系統提示，并要求結束輸入

　　2．圖書(shū)管理員確認借書(shū)完成

　　5b．讀者有該書(shū)的預定記錄

　　1. 刪除該書(shū)的預定信息

　　結構化設計要求模塊間的耦合程度盡可能小。

　　為此應：

　　用過(guò)程語(yǔ)句調用其他模塊

　　模塊間的參數作數據用

　　模塊間的參數盡可能少

　　總原則：盡量使用數據耦合，少用控制耦合，限制公共耦合的使用范圍，完全不用內容耦合。

　　結構化模塊詳細設計的建模工具

　　程序流程圖（程序框圖）

　　盒圖（NS圖）

　　PAD圖（問(wèn)題分析圖）

　　程序設計語(yǔ)言（PDL）

　　面向對象方法的特點(diǎn)

　　對象、類(lèi)、屬性和操作

　　封裝、隱藏

　　消息

　　繼承

　　多態(tài)

　　關(guān)系

　　UML的構架—4+1視圖中的具體內容。 略過(guò)

　　“購買(mǎi)商品”用例規格說(shuō)明

　　參與者：出納員（主）、顧客

　　目標：完成一次商品銷(xiāo)售和支付

　　前置條件：管理員必須已經(jīng)啟動(dòng)系統，出納員必須已經(jīng)登錄到這個(gè)系統

　　后置條件：銷(xiāo)售信息正確的記錄到系統中

　　觸發(fā)條件：顧客帶著(zhù)所要購買(mǎi)的商品來(lái)到一個(gè)POS機終端

　　主事件流（主成功場(chǎng)景/基本路徑）：

　　出納員將每項商品的信息錄入系統

　　商品信息錄入完畢后，系統計算商品價(jià)格總額

　　出納員通知顧客商品總額

　　顧客支付現金，出納員確認收取現金

【軟件工程的總結】相關(guān)文章：

對老板總結感想總結二篇03-20

學(xué)科總結03-20

電場(chǎng)公式總結06-08

離�？偨Y精選范文03-19

工會(huì )總結范本03-19

總結電熱的作用12-09

FLASH教程總結01-20

香茅做法總結03-19

工會(huì )總結精選范文03-20