系統分析與設計心得(精選多篇)

第一篇：系統分析與設計心得

系統分析師對考生的綜合素質要求較高，考查的知識面很廣。但分析歷年考題可以發現，雖然考試知識面廣但考試內容並不是很深。因此，這就要求我們注意平時積累，經常通過網絡、講座、學術會議等途徑及時瞭解一些流行技術熱點和業界最新動態。

【注意點：注意平時積累，關注技術熱點和業界動態。】

2、多做項目，在實踐中鍛鍊提高

如果説平時積累的各個知識點是一粒粒寶貴的珍珠的話，那麼項目經歷則是將這些珍珠串聯起來的一根紅線。“紙上得來終覺淺，絕知此事要躬行”。軟件工程是一門實踐性、綜合性非常強的專業，如果沒有參加過完整的實際項目，就難以從根本上理解書本上所學的理論知識，就難以真正領會軟件工程的思想精髓。同時，在做項目時還要勤于思考，無論是作為主持者還是作為一個普通的程序員，都應該去潛心思考為什麼要這樣設計、這樣設計的優點是什麼、有哪些不足，如果你是設計師的話你又會怎樣設計？經常做這樣的換位思考，會不自覺地提高自己的系統分析和設計能力，積累豐富的項目經驗，這對下午一的考試來説是非常有益的。

【注意點：勤于思考。】

3、注意提高個人文檔編寫能力

一些軟件工程師有個不好的習慣，那就是隻喜歡鑽研具體的技術點而不注重提高文檔編寫能力。他們的一個通病是做得多、寫得少，在某一個具體的技術領域上往往表現得非常優秀，但寫出的文檔質量實在難以恭維。作為一個合格的系統分析師文檔編寫能力是必不可少的基本素質，也是下午二考試的考查重點。

文檔編寫能力不僅對於應試是十分必要的，而且在實際工作也是非常重要的。因此，我們應當在平時多做這方面的訓練，多思考、多動筆，努力提高自己文檔編寫能力。

【注意點：實際工作中的文檔編寫能力。】

4、掌握評卷專家心理，注意論文寫作技巧

在下午二的考試中，應注意把握評卷專家的心理狀況。根據希賽it教育研發中心的著名軟考專家張友生所説的，評卷專家不可能把你的論文一字一句地精讀，要讓他短時間內瞭解你的論文內容並認可你的能力，必須把握好主次關係，論文的組織一定要條理清晰。一般説來，項目概述部分評卷專家會較認真看，為讓評卷專家對你所做的項目產生興趣，這裏可適當吹捧。在論文陳述部分應當按主次關係分條進行陳述，首先最好開門見山指出你所採取的措施，然後指出你為什麼這樣做，這樣做有何優點，克服了以前做法的哪些缺點等等。在分條陳述時最好一個問題一個自然段（自然段千萬不要過長），在每個自然段首先要有一個主題句，主題句簡明扼要地描述本段的中心思想。

在論文撰寫中，切忌大談空洞的理論知識或不懂裝懂，以專家的姿態高談闊論。應當將重點放在彙報你自己在項目中所做的與論題相關的工作，讓評卷專家相信你確實做過這方面的項目而且達到了相應水平。

在下午二考試時間的分配上，建議首先花3--5分鐘根據個人特長選定題目，然後花10—15分鐘左右整理一下所掌握的素材，列出提綱，即你打算談幾個方面，每個方面你是怎麼做的，收效如何等等，簡明扼要地寫在草稿紙上。

【注意點：主題把握。】

5、張友生的書，不能不讀

要想通過系統分析師考試，不但需要多做項目，而且有關全國著名的軟考輔導專家張友生老師的書是不可不讀的。

第二篇：學習電子商務系統分析與設計的心得體會

學習電子商務系統分析與設計的心得體會

《電子商務系統分析與設計》系統地介紹了電子商務系統的規劃、分析、設計、實施與運行管理的基本概念、方法、技術和相關案例。從結構上可以進一步分為4個部分：概述部分，主要説明電子商務系統分析設計的基本概念、內容、過程與方法；系統規劃、分析與設計部分，主要説明系統規劃、分析、設計的方法、內容和工具；系統實施與維護部分，涵蓋電子商務系統的開發與集成、測試、部署、維護、審計與評價；案例部分，給出了兩個完整的案例，從背景、規劃、分析、設計角度幫助我們進一步理解電子商務系統的規劃、分析與設計。圍繞電子商務系統開發過程的各個階段，系統地闡述了電子商務系統開發的思想、方法和技術，包括系統的規劃、分析、設計、實現與維護等內容，重點介紹了採用uml進行系統的分析與設計的方法；並從企業管理者和電子商務應用實踐的角度，對國內外一些典型的企業電子商務解決方案進行了介紹；最後結合實例闡述了運用struts、javaee1.5等新技術進行電子商務系統的設計與開發的過程，使我們能很好地把理論學習與實踐訓練更好地結合起來。

本課程結合電子商務系統領域的最新技術、方法和實踐，以及電子商務系統應用成果，從理論基礎、方法運用、技術基礎和實踐4個維度對電子商務系統做了較深入、全面的闡述。教科書共十章，第一章介紹電子商務系統的基礎概念和知識；第二章介紹電子商務系統建設的過程與方法；第三章介紹電子商務系統規劃的內容、方法和步驟；第四章介紹電子商務系統的分析方法與工具，重點利用uml進行了系統分析；第五章闡述了電子商務系統設計基礎與思想方法；第六章介紹電子商務支付系統、電子商務系統安全體系設計的思想方法；第七章介紹了電子商務系統的開發技術與模式，並結合實例完整介紹struts2框架web應用開發的基本過程；第八章介紹電子商務系統運行、維護與評價的知識和方法；第九章結合我國實際，介紹了國內外的電子商務系統解決方案；第十章結合實例和具體技術，系統的闡述了一個電子商務系統從分析、設計到實現的過程，讓我們通過一個電子商務系統的設計實踐和操作，消化和理解所學的理論知識。

本課程在繼承軟件工程和信息系統分析與設計的思想,方法,技術和工具的基礎上,從系統化的思想及結構化開發方法入手,全面介紹電子商務系統特色,規劃方法,系統分析及設計,並依據電子商務自身的特點,着重針對網站設計,支付系統設計及安全系統設計進行分析和介

紹。本實驗課程使學生進一步理解和掌握所學各種電子商務系統分析和設計的方法.熟練掌握系統分析和設計建模軟件.。

本課程目的是為了讓我們能夠全面瞭解應用系統的整個電子商務系統的開發建設流程，並掌握電子商務系統開發的相關技術：

（1）掌握電子商務系統的分析方法；

（2）掌握電子商務系統的(請繼續 關注本站)總體設計方法；

（3）學會使用visio軟件構建電子商務系統數據流程圖,use case圖以及活動圖；

（4）體會應用軟件工程的設計思想進行電子商務系統開發的過程與方法。

通過本課程設計，便於我們全面理解電子商務系統規劃、分析與設計知識，並掌握操作方法，而不是獨立地學習某單方面的操作技術；另一方面實用性較強，我們認真完成本書實驗後，基本上可以勝任電子商務系統規劃、分析、設計及實現工作。

學習這門課程，使我對電子商務網站的開發有了一定的瞭解。掌握了電子商務系統的基本概念、特徵及其結構。瞭解電子商務系統開發技術和發展方向，理解電子商務生命週期的概念、特徵及其作用。能夠按要求撰寫電子商務系統規劃報告，基本掌握uml需求分析思路和方法，能結合運用實際撰寫系統分析報告。熟悉電子商務平台技術，包括操作系統、應用服務器、中間件技術等。基本瞭解電子商務支付系統與安全系統。初步掌握一些電子商務網站客户端技術。能正確理解電子商務系統評價的作用，並掌握評價指標體系設計的思路等等。

通過一系列的實驗讓我知道了基礎的電子商務分析的方法，掌握對電子商務系統進行系統總體結構設計及應用系統設計的內容及方法。加深理解了在課程中、書本上學到的知識和理論，並使其在課題研究中得到運用而且讓我得到了實踐的收穫。

希望在以後的實習實踐中多接觸、對比一些案例能夠增長對網上電子商務系統設計的一些知識。

0911061237

朱寶

第三篇：信息系統分析與設計學習心得

信息系統分析與設計學習心得

通過近10周的學習，我覺得信息系統分析與設計這門課程收穫還是挺大的。我覺得，如果我們決定要做一件事，就得對這個系統有一個整體得把握，首先要進行系統的規劃和選擇，接着就是系統的設計，其中系統設計包括三個部分：1.確定系統需求；2.系統需求結構化：過程建模，這一步驟主要就是畫數據流圖（dfd）；3.系統需求結構化：概念數據建模，這一過程主要是畫實體—關係圖（erd）。然後就是進行系統設計，系統設計包括設計人機界面和數據庫設計。最後一步就是系統的實現與運行。

在做信息系統分析與設計的大作業的時候，我和我們的小組成員曾經去實地考察過，雖然最後並沒有被接待，但還是小有收穫的。通過實地考察，我們能更清晰地瞭解我們系統所要實現的功能，甚至説讓它比現有系統更加完善。當然，我們做東西，也是要追求進步，如果説做出來的東西和以前的系統都沒什麼兩樣，這樣意義也不大。不過，這也得是在我們能力所及的範圍內，我們得適當地把握好自己的時間和現有資源進行適當的設計。相信自己的努力還是能有一個很好的結果的，我們得對自己的發展有一個好的概括。信息系統分析與設計的大作業從第一週到第九週一直伴隨着我們，説實在話，一直覺得自己有做不完的作業，剛開始還有些抱怨，但隨着作業的進行，我們慢慢看到了自己的小小成果，覺得付出有了回報，並開始樂在其中。在這期間，徐老師也一直鼓勵我們，他告訴我們，只要堅持做下去，我們會收穫到成功的喜悦的！

現在，我們已基本完成了大作業分析階段，在我和小組成員的協作下，總算按時完成了。在分析階段，我們也遇到了很多問題，比如剛開始畫數據流圖時，visio用的不是很熟練，數據流圖中的數據流、數據存儲、過程、源點和宿點不知

道怎樣連接，層與層之間也不知如何區分，有時候甚至想要放棄。還好有老師的鼓勵與指導加上小組一起努力，我們克服了這一難關。在畫er圖的時候遇到的問題就相對少了一點，因為以前學習數據庫的時候就畫過er圖了，所以在畫的過程中就相對輕鬆一點。接下來就是系統的設計了，時間還蠻緊迫的，我們仍需努力。

我作為小組的組長，從中真的學習到不少知識。老師説過，組長應該做的比別人更加多，才能夠勝任。我們現在還沒有達到“喝茶看報紙”的層次，那得等到我們具備了足夠的能力，所以要想達到那個高度，我們現在應該更加努力。負責的整個過程中，我必須把握好進度，如果一步跟不上，可能就會步步跟不上。我們小組成員也很配合，基本不需我太多督促。在對我們所要實現的功能有了個整體的把握的情況下，我們製作出了令自己還算滿意的圖形。現在我覺得自己基本可以熟練運用visio了，這也算是一大收穫吧！

總的來説，這次這次信息系統分析與設計的課程設計讓我獲益匪淺，以前只是紙上談兵，沒有親自實踐，不知道理論上升到實踐路程的艱辛。通過這次自己親自選題、實地考察、繪製dfd、er圖到完成分析，我體驗了其中的不容易，也嚐到了其中的甜頭。我們還會繼續努力，更好的完成下面的工作。

0963710205 秦曉雅

第四篇：信息系統分析與設計

《信息系統分析與設計》考試題目及評分標準

下週一（11月26日）中午12點之前由班長或學習委員收齊各班紙質版本作業，週二收齊交給任課老師。

請注意論文封面、格式以及老師強調的論文重點，打印並裝訂好交給班長或學習委員。 考試題目：（任選其一）

設計一個銀行存取款管理信息系統。

要求具有下面的功能：①儲户憑身份證在銀行開户，銀行賬户中保存儲户姓名、聯繫電話、家庭住址等基本信息，並保存儲户每筆存取款業務數據。②儲户存款時，需提交存摺/卡號，由業務員在銀行賬户及存摺/卡上登記存款信息。③儲户取款時，還需提交密碼，以確認身份，在驗證取款合法性後，更新銀行賬户。④統計員每日統計存、取款情況，形成日存取款彙總表，提供給信貸管理部作為信貸主要依據。

設計一個物資採購及庫存管理業務管理信息系統。

要求具有下面的功能：①車間填寫領料單到倉庫領料，庫長根據用料計劃審批領料單，未批准的退回車間。②庫工收到已批准的領料單後，首先查閲庫存賬，若有貨，則通知車間前來領取所需物料，並登記用料流水賬；否則將缺貨通知採購人員。③採購人員根據缺貨通知，查閲訂貨合同單，若已訂貨，則向供貨單位發出催貨請求，否則就臨時申請補充訂貨。④供貨單位發出貨物後，立即向訂貨單位發出提貨通知。採購人員收到提貨通知單後，就可辦理入庫手續。接着是庫工驗收入庫，並通知車間領料。⑤此外，倉庫庫工還要依據庫存賬和用料流水賬定期生成庫存報表，呈送有關部門。

考核內容：

熟練掌握信息系統分析與設計的方法。具體考核的內容是：

1、編寫信息系統可行性報告。

2、編寫信息系統需求分析報告，繪製數據流圖。

3、編寫信息系統設計報告，繪製功能結構層次圖，數據庫設計，界面設計和硬件和軟件設計。

評分標準：

1、編寫信息系統可行性報告。（20分）

2、編寫信息系統需求分析報告，繪製數據流圖。（30分）

3、編寫信息系統設計報告，繪製功能結構層次圖。（20分）

4、數據庫設計（10分）

5、界面設計。（10分）

6、簡單的硬件和軟件設計。（10分）

第五篇：系統分析與設計方法讀書筆記

系統分析與設計方法讀書筆記

《系統分析與設計方法》，顧名思義，是論述軟件開發過程中涉及到的分析與設計過程的方法論。作者依照軟件開發過程將書劃分為四個部分：系統開發項目環境、系統分析方法、系統設計方法、系統分析和設計完成後的工作。同其他美國作者一樣，作者通過一個貫穿全書的案例--音階公司系統項目，向我們詳細地講解了開發一個軟件系統過程中設計到的知識。

第一部分“系統開發項目環境”介紹信息系統開發的概念和過程。第二部分“系統分析方法”涵蓋了生命週期前期活動、工具和技術，這些內容用於分析業務問題、説明信息系統業務需求以及制定業務和系統方案。第三部分“系統設計方法”涵蓋了生命週期中期活動、工具和技術，特別強調應用架構的概要設計和詳細設計、快速開發和原型設計、外部設計（輸出、輸入和界面）、內部設計（如數據庫和軟件工程）以及面向對象設計。第四部分“系統分析和設計完成後的工作”通過縱覽生命週期後期活動，透視系統分析和設計工作。

《系統分析與設計方法》這本書圍繞軟件開發這一中心，詳細講解了從需求分析到後期維護各個階段中，如何運用文檔與周圍的人員進行有效溝通和協作。文檔，作為各類人員之間的橋樑和紐帶，如使用得當，有以下幾個好處：

1.提高軟件開發過程的能見度。把開發過程中發生的事件以某種可閲讀的形式記錄在文檔中。管理人員可把這些記載下來的材料作為檢查軟件開發進度和開發質量的依據，實現對軟件開發的工程管理。

2.提高開發效率。軟件文檔的編制，使得開發人員對各個階段的工作都進行周密思考、全盤權衡、從而減少返工。並且可在開發早期發現錯誤和不一致性，便於及時加以糾正。

3.作為開發人員在一定階段的工作成果和結束標誌。

4.記錄開發過程中的有關信息，便於協調以後的軟件、開發、使用和維護。

5.提供對軟件的運行、維護和培訓的有關信息，便於管理人員、開發人員、操作人員、用户之間的協作、交流和了解。使軟件開發活動更科學、更有成效。

6.便於潛在用户瞭解軟件的功能、性能等各項指標，為他們選購符合自己需要的軟件提供依據。

也正是基於這樣的好處，軟件行業才會定義、開發各種溝通表達工具和建模語言來統一溝通方法，從而便於各種人員的團結合作。以uml為例。從1989

年到1994年,建模語言數量從不到十種增加到了五十多種。90年代中,又一批新方法出現,其中最引人注目的是booch 1993、oose和omt-2等。但到目前為止，uml這一統一建模語言脱穎而出，它貫穿軟件開發週期中的每一個階段，並被omg採納作為業界的標準。就如書中所講，uml是一個標準的圖形表示法，它不是面向對象的分析和設計，也不是一種方法，它僅僅是一組符號。uml是在開發階段，説明，可視化，構建和書寫一個面向對象軟件密集系統的製品的開放方法。作為一種模型語言，它使開發人員專注於建立產品的模型和結構，而不是選用什麼程序語言和算法實現。當模型建立之後，模型可以被uml工具轉化成指定的程序語言代碼。所以説，運用優秀的溝通工具與各種角色進行有效地溝通在一定程度上決定着系統能否保質保量的成功完成。在這個崇尚團結與合作的社會，作為新一代的軟件開發人員，我們更應該認真學習書中説講的各種文檔編寫方法，更好的運用到實際開發中去。

首先，需求分析人員從接觸到深入瞭解客户業務有一個漸進的過程，如果一開始就深入到業務的細節中去，不但容易迷失方向，而且很容易顯露出你對業務的無知，客户會因此而失去與你溝通的興趣。

其次，溝通雙方都有自己習慣的溝通方式。所以在雙方能夠達成默契之前，不要急於深入業務細節，而是圈定範圍，先就一些大框框進行溝通，藉此瞭解客户的溝通方式。客户是喜歡開放型問題還是封閉型問題？客户是很健談還是很含蓄？客户是主導型溝通者還是被動型溝通者？客户是具有很強邏輯思維的人，可以將一個問題有條不穩地講清楚，還是一個發散型思維的人，總是沒有什麼目的地想到什麼就講什麼？如果雙方的溝通方式不能切合 rf4ss，必定會造成溝通的障礙。

再次，客户的時間是有限的，很多時候不能有整塊的時間來配合需求調研。由於項目的週期也是有限的，因此每一次會面都需要爭分奪秒，用最快的時間把問題搞清楚。另一方面，客户通常不會為需求調研做好準備，往往是等着回答問題的。如果需求分析人員寄希望於客户能有條不理的把一套業務都能講解很清楚，整個業務形成閉環往往是很不現實的。這就要求需求分析人員根據經驗提前要做好調研計劃和內容，逐個進行落實。

系統分析與設計的方法主要包括結構化生命週期法（又稱瀑布法）、原型化方法（迭代法）、面向對象方法。

按時間過程來分，開發方法分為生命週期法和原型法，實際上還有許多處於中間狀態的方法。原型法又按照對原型結果的處理方式分為試驗原型法和演進原型法。試驗原型法只把原型當成試驗工具，試了以後就拋掉，根據試驗的結論做出新的系統。演進原型法則把試好的結果保留，成為最終系統的一部分。 按照系統的分析要素，可以把開發方法分為三類：

①面向處理方法（processing oriented ，簡稱po）。

②面向數據方法（data oriented ，簡稱do）。

③面向對象的方法（object oriented ，簡稱oo）

系統分析和設計應遵循的原則有：

系統開發是面向客户的，應從客户的角度考慮。

諸如系統開發生命週期之類的產品更新換代機構應該在所有的信息系統開發項目中建立起來。

信息系統開發的過程並不是一個順序的過程，它允許步驟的重疊和倒轉等。 如果系統的成功可能性受到很大限制時，應取消整個項目。

文檔材料是系統開發生命週期中重要的可遞交成果，應加以重視

最後總結下，學完《系統分析與設計方法》這門課程再加上老師在課堂上的一些講解以及以前學習過程中的收穫，我對於系統分析與設計有了進一步的理解，能高屋建瓴的看待系統分析與設計整個過程的步驟以及增加了一些開發設計中的重要事件的理論知識。