第一篇：關于伙伴系統的分析及應用心得

關于伙伴系統的分析及應用心得

看完書本后，對于伙伴系統的初步理解就是伙伴系統彌補了固定分區和動態分區不足，是介于兩種不同分區之間的一個優化方案。那么什么是固定分區和動態分區呢？固定分區分配時最簡單的一種可運行多道程序的儲存管理方式。用戶空間被劃分為若干個固定的大小區域，每個分區只裝入一道作業，這樣一來，可以幾道作業并發運行。當一有空閑時，可以從外存的后備作業隊列中選擇一個適當大小的作業裝入該分區，由此往復運行作業。這就好比好多裝滿貨物的貨車進入倉庫卸貨，倉庫有很多根據車型大小而設置的大小不同的通道，不同車型的貨車排列在不同的車道，然后相同車型的貨車在同一車道依次排隊卸貨，使得作業有序，順暢的運行。

動態分區分配是根據進程的實際需要，動態得分配內存空間。其中動態分區實現可變分區分配時，涉及到分區分配中所用的數據結構、分區分配算法和分區的分配與回收操作三個問題。動態分區分配就好比肯德基的點餐前臺，肯德基點餐前臺也有好多一個服務點，人少的時候相應地減少服務點，用餐高峰期開放所有的服務點以加快服務速度，這樣可以使得資源分配更加合理，避免了不必要的資源浪費，提高了作業效率。

但是固定分區限制了活動進程的數目，每次都只能相應地進行作業，進程對于空閑分區的大小要求比較高，使得作業不靈活，降低了內存的空間利用率。而動態分區算法復雜，回收空間是要進行分區合并，對于系統的開銷較大，相當于肯德基的前臺服務點總是處在一種變動的狀態，需要經常性地關注客流量以及對于工作人員的安排，這樣一來，加重了工作量。

伙伴系統既能在系統的運行過程中不斷地劃分空閑分區，并根據分區的大小進行分類，然后相同的空閑分區單獨設立一個空閑分區雙向鏈表，同時也能在進程需要系統為其分配一個存儲空間時，通過計算并找到合適的空閑分區分配給進程。但是在尋找合適分區的時候存在多種情況，空閑分區的查找是在不同的分區鏈表中查詢，若一個分區鏈表中的空閑分區已經耗盡，則系統將在另一個大小的分區鏈表中尋找，然后將找到的分區鏈表分割，一個分區用于分配，另一個加入相應的空閑分區鏈表。食堂的千層餅阿姨在賣千層餅是時候將千層餅切成很多一份，然后再根據學生的需求再切成很多一份，千層餅是按重量來賣，假如一個學生需要2塊錢千層餅，而阿姨在切千層餅的時候少切了3毛錢，然后阿姨又從大塊的千層餅中切了5毛錢千層餅，再從5毛錢的千層餅中分割成一塊3毛錢的跟一個2毛錢的兩份千層餅，然后2毛錢的千層餅可以留到下一次分配給另一個同學。在一次分配中也可能進行多次分割。伙伴系統是一種有效的內存分配和釋放方法，得到了大量應用。

第二篇：關于伙伴系統的分析及應用心得

關于伙伴系統的分析及應用心得

說實話，在第一眼看到這個伙伴系統的時候，我的腦海里是小時候和小伙伴們一起玩耍的的場景。所以伙伴系統在我的第一印象里應該是一個系統內部的一種自我的團結、協調的、大家庭中誰都能參與其中的系統。

直到我看書，對伙伴系統的理解貌似更模糊了，或許是書上太專業了的緣故吧。在我的理解是：比如商店里只有賣6米、10米、18米的紅地毯，這時來了個只需要4米的，那么我們可以在10米的哪里分出4米的剩下的6米就放在賣6米的一起，這樣就可以充費利用而不會產生什么浪費。

總的來說，我覺得伙伴系統的最好的一點就是內存空間的利用率高，雖然也避免不了產生內部碎片，好比說上面的例子如果恰巧只要17米的，那么只能買18米的就會浪費1米，以那么來說1米就沒多大用處了，這就是所謂的碎片。其算法較動態分區分配要簡單，較固定分區分配要復雜。所以說伙伴系統是對固定分區和動態分區這兩種內存方式的折衷方式。

計科101班李燕10203109

第三篇：用友ERP-U8系統分析和案例應用

用友ERP－U8系統分析及案例應用

一 系統分析

用友ERP－U8企業應用套件（簡稱用友ERP-U8）是中國ERP普及旗艦產品，是中國用戶量最大、應用最全面、行業實踐最豐富的ERP，并與中國企業最佳業務實踐相結合，形成了中國企業最佳經營管理平臺。

它充分適應中國企業高速成長且逐漸規范發展的狀態，為廣大中小企業連接世界級管理，是蘊涵中國企業先進管理模式，體現各行業業務最佳實踐，有效支持中國企業國際化戰略的信息化經營平臺。在今天，它不僅成為管理者進行企業運營與管理的桌面工具，更是企業實現精細管理、敏捷經營的利器。作為中國企業最佳經營管理平臺，用友ERP—U8傳承“精細管理 敏捷經營”設計理念，符合“效用、風險、成本”客戶價值標準，代表了“標準、行業、個性”的成功應用模式。

用友ERP-U8是一套企業級的解決方案，滿足不同的競爭環境下，不同的制造、商務模式下，以及不同的運營模式下的企業經營，實現從企業日常運營、人力資源管理到辦公事務處理等全方位的產品解決方案。用友ERP－U8是以集成的信息管理為基礎，以規范企業運營，改善經營成果為目標，幫助企業“優化資源，提升管理”，實現面向市場的贏利性增長。

用友ERP-U8是一個企業綜合運營平臺，用以解決不同滿足各級

管理者對信息化的不同要求：為高層經營管理者提供大量收益與風險的決策信息，輔助企業制定長遠發展戰略；為中層管理人員提供企業各個運作層面的運作狀況，幫助做到各種事件的監控、發現、分析、解決、反饋等處理流程，幫助做到投入產出最優配比；為基層管理人員提供便利的作業環境，易用的操作方式實現工作崗位、工作職能的有效履行。

賬套管理

? 賬套指的是一組相互關聯的數據，每一個企業（或每一個核算部門）的數據在系統內部都體現為一個賬套 ? 賬套管理包括賬套的建立、修改、引入、輸出等

賬管理

? 每個賬套里都存放有企業不同的數據，稱為賬 ? 賬的建立、引入、輸出和結轉上年數據、清空賬等

系統操作員及操作權限的集中管理

? 定義角色、設定系統用戶和設置功能權限

設立統一的安全機制

? 設置數據自動備份、清除系統運行過程中的異常任務

二 操作流程

1.啟動系統管理與設置作員 2.建立新賬套

3.財務分工與權限設置 4.修改核算賬套

1.【開始】->【程序】->【用友U8】->【系統服務】->【系統管理】->【系統】->【注冊】，進入系統管理

2.···系統管理窗口->【權限】->【操作員】->【增加】 1.建立新賬套應，應先進行操作員設置，以便建立賬套后建立會計主管，及為操作員進行權限分配。

2.所設操作員一旦起用，則不能被刪除。3.操作員姓名與編號必須輸，且唯一。

? 【開始】->【程序】->【用友U8】->【系統服務】->【系統管理】->【賬套】->【建立】，依次輸入賬套信息、單位信息、核算類型（輸入核算本位幣及賬套主管等信息）、分類信息、編碼方案、數據精度。

1.賬套：核算單位的一套獨立完整的賬簿體系，每個賬套有一個“賬套代碼”。2.可同時開32768套

3.第一次使用系統，需建立賬套與賬簿，以后每個新的財務開始，只需新建賬簿。

4.企業性質、科目級長、本位幣、啟用日期等一經啟用，在一個會計中是不允許改變的。

確定賬套主管：系統管理窗口->【權限】->【權限】

給操作員賦權：系統管理窗口->【權限】->【權限】，選擇操作員，【增加】（只能由系統管理員或賬套主管操作）操作

以賬套主管的身份注冊，選擇相應的賬套，進入系統管理界面。【賬套】->【修改】，進入賬套功能 只有賬套主管才有權修改相應的賬套。說明

只有賬套主管才有權修改相應的賬套。

在賬套的修改中，可以對本年未啟用的會計期間修改其開始日期和終止日期。核算體系的建立

1.系統管理的啟動與注冊 2.增設操作員信息 3.建立核算賬套 4.分配操作員權限 5.修改核算賬套

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

讀《系統分析與設計方法》一書有感

作為一個軟件專業的學生，理解和掌握系統分析與設計的知識是必不可少的。在閱讀《系統分析與設計方法》一書中以及加上老師教導，我學到了很多東西，收獲不少。

系統就是由若干可以相互區別、由相互聯系并且各自獨立的單元組成各個子系統之間同樣是獨立而又相互聯系的。系統具有集合性、相關性、目的性、整體性和環境適應性。在開發完成一個軟件項目的過程中，系統工程必須經過開發階段、建造階段、運行階段、更新階段、維護階段。

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

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

按照系統的分析要素，可以把開發方法分為三類：

①面向處理方法（Processing Oriented，簡稱PO）。

②面向數據方法（Data Oriented，簡稱DO）。

③面向對象的方法（Object Oriented，簡稱OO）。

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

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

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

信息系統開發的過程并不是一個順序的過程，它允許步驟的重疊和倒轉等。

如果系統的成功可能性受到很大限制時，應取消整個項目。文檔材料是系統開發生命周期中重要的可遞交成果，應加以重視。在本書的第一部分中，主要集中于系統分析和設計的整體描述，包括系統分析和設計方法的環境，信息系統構件，信息系統開發，項目管理。期中印象比較深刻的是系統開發過程的能力成熟度模型（CMMI）。信息系統和軟件的CMM框架用來幫助改善其系統開發過程的成熟度。CMM包括了五個成熟度等級：初始級、可重復級、已定義級、已管理級、優化級。期中，每個等級都是下一個等級的必須條件。

在軟件開發過程中需求分析階段是至關重要的一個階段，需求分析階段可能被稱為定義階段或者邏輯設計階段。需求分析階段的第一個任務是確定需求，在這個階段至少將目標轉換成為滿足其需要的功能需求和非功能需求的框架。在這個階段需要交付的成果是功能需求和非功能需求的草稿。在初步定義完了功能需求和非功能需求后，得排列需求的優先次序。如果一個項目落后于進度或者超出預算，知道哪個需求比其他需求更重要可能是很有用的。在排列需求的優先次序中可以使用到時間盒的技術。需求分析并不會真正的技術，因為企業需要具有快速適應不斷變化的需求和機會的能力。信息系統不能比企業自身的響應技術還慢。

在學習本書第二部分的時候，我了解到了需求分析在整個項目開發中的作用以及成為整個項目主導的因素。只要好的需求才能設計開發出好的軟件項目。在項目開發過程中，我們還可以利用圖表的形式來簡化方便人員的開發設計。期中有五種圖表是系統分析師常用的：類圖、用例圖、協作圖、順序圖、狀態圖。期中用例圖是用例建模的產物，它以圖形化的方式將系統描述成用、參與者（用戶）及其之間的關系。簡單的說就是用直立的小人來表示參與者（用戶），用圓圈來表示用例，他們之間以箭頭的形式來連接。關系包括了：關聯關系、擴展關系、使用關系、依賴關系、繼承關系。但是書上沒講到《include》關系，跟老師的講解有點出路。老師在講義上通過畫圖的方式很好的解釋了《include》和《extend》的關系。

數據建模這一章節中，我了解了數據建模的含義，它是一種為數據庫定義業務需求的技術。數據建模中比較重要的概念有實體和屬性之間的關系，關系是連接實體的一個時間，或者僅僅是存在于實體之間的邏輯關系。關系有很多種類，多對多、一對多、一對

一、等等。這些關系的圖形化符號記起來很不容易，但是我自己想到了一個比較容易記憶的簡單的方法。一個就用 “|”表示，零個就用“0”表示，多個就用“<”表示，然后根據相應的說明來選擇。比如零個或一個（0|），一個或多個（|<）。過程建模是一種組織和記錄數據的結構和流向的技術，它記錄系統的“過程”和有系統的“過程”實現的邏輯、策略和程序。期中也介紹到了數據流圖（DFD），數據流圖是一種描述通過系統的數據流以及系統實施的工作或處理過程的工具。我覺得數據流圖DFD的最大的優點就是容易閱讀，因為數據流圖僅有三種符號和一種連接：圓角矩形表示要完成的過程或者工作，正方形表示外部代理（系統的邊界），開放的方框表示數據存儲（可以是文件或者數據庫），箭頭表示數據流（可以是輸入和輸出，或者是表示到過程和來自過程）。統一建模語言UML的目的就是對面向對象系統進行可視化、評述、和文檔化。它適用于系統開發從需求規格描述道系統完成后測試的不同階段（需求分析階段、分析階段、設計階段、編程階段、測試階段）。UML2.0的模型主要圖包括了：用例圖、活動圖、類圖、對象圖、狀態機圖、組合結構圖、交互圖、定時圖、組件圖、部署圖和包圖。在理解這章的過程中，我感覺比較輕松，但是把一些關系，事件，實體等等用圖形化的形式表示出來還是非常難的。用UML設計面向對象系統時候，我們得準確的找到實體類、接口類、控制類、持續類、系統類和設計關系。在面向對象設計的過程中，主要包括了一下活動：對用例模型加以精煉以反映實現環境；建模支持用例情景的對象交互、行為和狀態；修改對象模型以反映實現環境。

前面說到需求分析是整個軟件項目開發中最重要的一環，其實我覺得可行性分析也是跟需求分析一樣的重要。因為信息是一個必須經過檢驗的重要資本投入，就像市場要檢驗一個新產品，系統分析員應該考慮投資能夠收回嗎？是否有其他投資能夠帶來比預期更高的回報。要說他們的區別，我個人覺得是：可行性分析是要決定“做還是不做”。需求分析是要決定“做什么，不做什么”。可行性分析報告有六個準則：運行可行性、文化可行性、技術可行性、進度可行性、經濟可行性。只有進行了可行性分析報告，才能夠確定企業是否要 做這個項目。如果說在可行性報告中顯示沒有成功的可能，那么就沒有必要再做需求分析了，整個項目就不會做下去了。進行可行性分析報告可以避免項目中途告終的結果，在系統開發過程中舉足輕重。

數據庫開發與設計這章，感覺書上講解的沒有老師講的詳細。書上并沒有提到范式，但是在課堂上我了解到數據庫設計的范式。有第一范式、第二范式、第三范式、BC范式等。等級越高，數據冗余越少，對系統調用數據庫更方便。數據庫的核心是DBMS，DBMS的核心是數據庫引擎，引擎響應專門的命令以創建數據庫結構，然后創建、讀取、修改和刪除數據庫中的記錄。DBMS使用數據定義語言（DDL）創建記錄類型、字段和結構化關系，還定義了數據庫視圖；DBMS還是用數據處理語言（DML）用來創建、讀取、修改和刪除數據庫中的記錄。但是并非所有數據庫的DBMS都被要求使用DDL和DML。看完這章，總結了一下建立關系數據庫模式的步驟，首先要為每個實體類型建立一張表，然后為每張表選擇一個主鍵，同時增加外鍵來表示一對多的關系，接著還可以建立幾個新表來表示多對多的關系，然后還得定義參照完整性約束，評價模式質量，并且進行必要的改進，最后為每個字段選擇適當的數據類型和取值約束。數據庫在系統開發的過程中是必不可少的，幾乎所有框架類型都得用到數據庫，它也是MVC框架的底層核心。

對于本書的還有一個比較映像深刻的就是UI（user interface），用戶界面設計。一個良好的用戶界面應該為用戶提供友好的使用方式，通過用戶界面用戶可以同應用程序打交道，處理輸入并且獲得輸出。Galitz曾經提出過用戶界面設計的原則：理解你的用戶及任務、讓用戶參與界面設計、在實際用戶中測試系統、進行迭代設計。記得以前大二的時候學習JAVA的時候，我曾經開發過基于圖形用戶界面（GUI）的聊天軟件，不過當時的界面設計完全設計的是隨心所欲，并沒有理論作為指導。在學習VB課程的時候學過UAR，簡單的了解了一些關于界面友好化設計的原則。這本書也給出了用戶界面設計過程的幾個步驟：1.以圖表形式描述用戶界面對話；2.原型化對話和用戶界面；3.獲得用戶反饋；4.如果需要，回到1步或者2步。

最后總結下，雖然我沒用把這本書的每一個地方都認真精讀，有些地方略讀的，但是看完整本書后我收獲很大。讀完《系統分析與設計方法》這本書再加上老師在課堂上的一些講解以及以前學習事件過程中的收獲，我對于系統分析與設計有了進一步的理解，能高屋建瓴的看待系統分析與設計整個過程的步驟以及增加了一些開發設計中的重要事件的理論知識。

對于系統分析的心得

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

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

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

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

如果說平時積累的各個知識點是一粒粒寶貴的珍珠的話，那么項目經歷則是將這些珍珠串聯起來的一根紅線。“紙上得來終覺淺，絕知此事要躬行”。軟件工程是一門實踐性、綜合性非常強的專業，如果沒有參加過完整的實際項目，就難以從根本上理解書本上所學的

理論知識，就難以真正領會軟件工程的思想精髓。同時，在做項目時還要勤于思考，無論是作為主持者還是作為一個普通的程序員，都應該去潛心思考為什么要這樣設計、這樣設計的優點是什么、有哪些不足，如果你是設計師的話你又會怎樣設計？經常做這樣的換位思考，會不自覺地提高自己的系統分析和設計能力，積累豐富的項目經驗，這對下午一的考試來說是非常有益的。

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

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

文檔編寫能力不僅對于應試是十分必要的，而且在實際工作也是非常重

要的。因此，我們應當在平時多做這方面的訓練，多思考、多動筆，努力提高自己文檔編寫能力。

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

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

想。

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

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

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

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

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

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

設計與開發的過程，使我們能很好地把理論學習與實踐訓練更好地結合起來。

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

第十章結合實例和具體技術，系統的闡述了一個電子商務系統從分析、設計到實現的過程，讓我們通過一個電子商務系統的設計實踐和操作，消化和理解所學的理論知識。

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

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

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

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

掌握電子商務系統的總體設計方法；

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

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

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

學習這門課程，使我對電子商務網站的開發有了一定的了解。掌握了電子商務系統的基本概念、特征及其結構。了解電子商務系統開發技術和發展方向，理解電子商務生命周期的概念、特征及其作用。能夠按要求撰寫電子商務系統規劃報告，基本掌握uml需求分析思路和方法，能結合運用實際撰寫系統分析報告。熟悉電子商務平臺技術，包

括操作系統、應用服務器、中間件技術等。基本了解電子商務支付系統與安全系統。初步掌握一些電子商務網站客戶端技術。能正確理解電子商務系統評價的作用，并掌握評價指標體系設計的思路等等。

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

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

0911061237

朱寶

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

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

在做信息系統分析與設計的大作業的時候，我和我們的小組成員曾經去實地考察過，雖然最后并沒有被接待，但還是小有收獲的。通過實地考察，我們能更清晰地了解我們系統所要實現的功能，甚至說讓它比現有系統更加完善。當然，我們做東西，也是要追求進步，如果說做出來的東西和以前的系統都沒什么兩樣，這樣意義也不大。不過，這也得是在我們能力所及的范圍內，我們得適當地把握好自己的時間和現有資源進行適當的設計。相信自己的努力還是

能有一個很好的結果的，我們得對自己的發展有一個好的概括。信息系統分析與設計的大作業從第一周到第九周一直伴隨著我們，說實在話，一直覺得自己有做不完的作業，剛開始還有些抱怨，但隨著作業的進行，我們慢慢看到了自己的小小成果，覺得付出有了回報，并開始樂在其中。在這期間，徐老師也一直鼓勵我們，他告訴我們，只要堅持做下去，我們會收獲到成功的喜悅的！

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

道怎樣連接，層與層之間也不知如何區分，有時候甚至想要放棄。還好有老師的鼓勵與指導加上小組一起努力，我們克服了這一難關。在畫er圖的時候遇到的問題就相對少了一點，因為以前

學習數據庫的時候就畫過er圖了，所以在畫的過程中就相對輕松一點。接下來就是系統的設計了，時間還蠻緊迫的，我們仍需努力。

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

總的來說，這次這次信息系統分析與設計的課程設計讓我獲益匪淺，以前只是紙上談兵，沒有親自實踐，不知道理論上升到實踐路程的艱辛。通過這次

自己親自選題、實地考察、繪制dfd、er圖到完成分析，我體驗了其中的不容易，也嘗到了其中的甜頭。我們還會繼續努力，更好的完成下面的工作。

0963710205 秦曉雅

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

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

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

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

要求具有下面的功能：①儲戶憑身份證在銀行開戶，銀行賬戶中保存儲戶姓名、聯系電話、家庭住址等基本信息，并保存儲戶每筆存取款業務數據。②儲戶存款時，需提交存折/卡號，由業務員在銀行賬戶及存折/卡上登記存款信息。③儲戶取款時，還需提交密碼，以確認

身份，在驗證取款合法性后，更新銀行賬戶。④統計員每日統計存、取款情況，形成日存取款匯總表，提供給信貸管理部作為信貸主要依據。

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

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

考核內容：

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

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

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

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

評分標準：

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

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

3、編寫信息系統設計報告，繪制功能結構層次圖。

4、數據庫設計

5、界面設計。

6、簡單的硬件和軟件設計。

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

《系統分析與設計方法》，顧名思義，是論述軟件開發過程中涉及到的分析與設計過程的方法論。作者依照軟件

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

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

《系統分析與設計方法》這本書圍繞軟件開發這一中心，詳細講解了從需

求分析到后期維護各個階段中，如何運用文檔與周圍的人員進行有效溝通和協作。文檔，作為各類人員之間的橋梁和紐帶，如使用得當，有以下幾個好處：

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

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

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

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

5.提供對軟件的運行、維護和培訓的有關信息，便于管理人員、開發人員、操作人員、用戶之間的協作、交流和了

解。使軟件開發活動更科學、更有成效。

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

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

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

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

其次，溝通雙方都有自己習慣的溝通方式。所以在雙方能夠達成默契之前，不要急于深入業務細節，而是圈定范圍，先就一些大框框進行溝通，借此了解客戶的溝通方式。客戶是喜歡開放型問題還是封閉型問題？客戶是很健談還是很

含蓄？客戶是主導型溝通者還是被動型溝通者？客戶是具有很強邏輯思維的人，可以將一個問題有條不穩地講清楚，還是一個發散型思維的人，總是沒有什么目的地想到什么就講什么？如果雙方的溝通方式不能切合 rf4ss，必定會造成溝通的障礙。

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

系統分析與設計的方法主要包括結構化生命周期法、原型化方法、面向對象方法。

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

①面向處理方法。

②面向數據方法。

③面向對象的方法

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

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

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

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

制時，應取消整個項目。

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

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