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

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

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

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，必定會造成溝通的障礙。

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

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

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

①面向處理方法。

②面向數據方法。

③面向對象的方法

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

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

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

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

制時，應取消整個項目。

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

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

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

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

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

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

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

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

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

①面向處理方法（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步。

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

對于系統分析的心得

第三篇：信息系統分析與設計心得報告

信息系統分析與設計

專 業：信息與計算科學班 級：姓 名：學 號：指導老師：

—認知實習報告 信122

河北建筑工程學院數理系

二零一五年七月

《信息系統分析與設計》

《信息系統分析與設計》這門課程是我們在大三下半學期開設的一門學科。它主要從信息系統的基本概念出發，按照信息系統的生命周期，系統、詳細地闡述了信息系統分析與設計的理論、方法和工具。是計算機專業類學生所要學的一門必不可少的課程。

《信息系統分析與設計》一書通過信息系統基礎、信息系統概論、信息系統建設、信息系統模型、信息系統規劃、領域分析、需求分析、信息系統體系結構設計、詳細設計、實現與測試、信息系統管理、信息系統的應用等十二章的內容讓我們對這門課程有了一個初步的認知。并且通過不斷地學習逐步加深我們對這一學科的認識。

信息系統是利用現代信息技術，處理組織中的信息、業務、管理和決策等問題，并為組織目標服務的綜合系統。在長達16周的學習之后，我們迎來了期待已久課程設計。在平時，我們每堂課都有認真的在聽講，并且從不遲到、不早退，更沒有逃過課。因此，我們有些自大的認為自己已經對這門課有了一定的了解，所學的東西都很扎實了，已經可以獨立地解決一些簡單的問題了。但是通過這一次課程設計，徹底地暴露了我們學習中的不足。做一個管理信息系統，并沒有我們以為的那么簡單。在開始設計之前，我們要進行一些系統調查，要了解這一系統是否滿足大眾的需要，確定我們的設計切實可行而不是在做無用功。同時也要考慮經濟、技術、社會等多方面的因素，才能確定是否應設計這一系統。

因為自己對知識的了解不夠深刻，使得我在課程設計中走了很多彎路，好多東西自己都不是很了解，只有通過不斷地翻閱書籍和上網查詢才能夠的已解決。不過我很珍惜這些彎路，它們使我的不足點充分的表露了出來。正所謂人在年輕時所犯的錯誤都會是今后寶貴的經驗。現在在學校中犯錯誤，總要好過今后在工作中犯錯誤。同時，我在知道了自己的這些不足之后，盡自己所能的有針對性的對自己學習中的缺陷進行彌補，這樣也能夠更好地完善自己的知識體系。

在課程設計后，老師還給我們安排了一周的課程實習，實習范圍很廣，不限時間、不限地點，給了我們一個充分發揮的空間。不過要求對實習過程有一個深刻的思考、總結。在我看來，僅一周的時間用來實習是不夠的。例如在大型企業的一個比較復雜的部門實習，一周的時間僅夠我們熟悉業務，根本不能對所實習的項目有一個更深入的了解，更不要說是有所感悟了。所以，在這周內我并沒有專門的尋找實習單位，而是針對我以前就從事的家教工作進行了深入的思考。

隨著信息技術日新月異的發展，互聯網已經涉及到了人們生活的方方面面，成為人們工作和生活中必不可少的組成部分。而我的家教工作也是在互聯網上的中介系統找到的，通過教一定的押金給管理者，然后負責聯系學生，給我們安排工作。不過，我發現這樣的安排雖然減少了我們尋找工作的時間，但是卻不能了解我們的服務對象的狀況。我們不知道學生的具體情況，無法針對性的制定教學計劃；學生對老師也不熟悉，不知道老師的教學路線。這樣會加長師生的磨合期，不利于家教工作的進行。

因此，在學習了《信息系統分析與設計》這門課程后，在信息系統已經廣泛應用于國民經濟和人們生產生活的各個方面的今天，我覺得我們可以設計一個家教信息管理系統。

當今時代的兩個顯著特點就是世界經濟一體化和以計算機為代表的信息技術的快速發展。我要設計的家教信息管理系統要經得起環境的挑戰，可以隨著計算機軟件和網絡技術不斷地前進而前進，隨著環境不斷地變化而變化的。家教信息管理系統要逐步發展，能更好地適應社會的發展需求。

這個家教信息管理系統應是建立在互聯網基礎上的一種信息交流平臺，面向所有網民提供服務。無論是找家教的學生還是做家教的教師，都可以通過該平臺進行信息方面的交流。任何網友都可以自由地查看、搜索、發布該家教信息平臺的信息。這個系統是區別于傳統的家教中介的系統。

我計劃開發家教管理系統是為了可以更好的了解家教教師、學生的特點。對系統的初步要求為：

1、系統可以管理家教教師的基本情況。

2、家教老師可以在網站上注冊，發布自己的基本信息，然后想要尋找家教的學生就可以看到教師發布的信息。在家教信息管理系統上，想要輔導的學生可以根據自己的需求尋找與自己最貼合家教。

3、學生也可以在網站注冊，發布一些自己的對老師的需求，而同時老師也可以通過這些需求尋找學生。

4、系統也提供了聊天功能，師生可以先通過交談再確定兩人之間是否合適。

5、注冊的學生可以發表帖子，討論話題，發表評論，也可以找到志同道合的朋友，共同學習。

針對系統功能我設計了功能模塊圖：

這只是我的一個初步的想法。具體的實現還要經過仔細調查之后才能開始。家教信息管理系統是我在學習了《信息系統分析與設計》之后，結合自己的家教體驗所設計的。通過對實習的深入思考，對家教信息管理系統的思考，我對《信息系統分析與設計》這門課不僅僅是了解的更深入了，而且也有了一定的興趣。并不像以前只是為了學習而學習，而是為了興趣而學習。因此，我為自己今后的學習做了一個簡單的規劃，希望通過這些規劃能夠更好地充實自己，提高自己的能力。1、2、3、4、5、6、熟練掌握信息系統分析與設計的基本理論知識。熟練掌握信息系統的分析方法、設計方法和實現技術。培養學習組織、分析研究的基本能力。

培養綜合運用所學知識分析和解決問題的基本能力。了解本專業發展前景以及與本專業相關領域的發展動態。尋找一些實習機會，培養實際工作的能力。

7、深入了解信息系統設計及開發方法的實際應用，掌握軟件工具及其應用情況；了解本專業業務范圍內的計算機運用生產與應用方法、信息組織形式、軟件開發紀實過程及常用技術方法。

8、了解所學專業在國民經濟建設中的地位、作用和發展趨勢,重點掌握一些信息管理技術的發展前沿。

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

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

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

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

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

【注意點：勤于思考。】

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

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

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

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

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

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

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

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

【注意點：主題把握。】

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

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

第五篇：軟件系統分析與設計

第1章

軟件工程基礎知識 1.1軟件工程知識體系

? 軟件需求（Software Requirements）? 軟件設計（Software Design）

? 軟件構造（Software Construction）? 軟件測試（Software Testing）? 軟件維護（Software Maintenance）

? 軟件配置管理（Software Configuration Management）? 軟件工程管理（Software Engineering Management）? 軟件工程過程（Software Engineering Process）

? 軟件工程工具和方法（Software Engineering Tools and Methods）? 軟件質量（Software Quality）

1.2軟件生存周期與軟件開發模型

? 1.2.1 軟件生存周期

? Boehm定義的軟件生存周期模型

? GB 8566-1988定義的軟件生存周期模型

? GB/T 8566-1995定義的軟件生存周期過程模型 ? GB/T 8566-2001定義的軟件生存周期過程模型 ? UP定義的軟件生存周期模型

? 1.2.2 軟件開發模型

? 瀑布模型（waterfall model）

? 快速原型模型（rapid prototype model）? 演化模型（evolutionary model）? 增量模型（incremental model）? 螺旋模型（spiral model）

? 噴泉模型（water fountain model）

1.3軟件質量模型與軟件質量管理

? 1.3.1 軟件質量模型

? 軟件產品的內部質量、外部質量和使用質量 ? 質量特性、質量子特性和度量

? 功能性：適宜性、準確性、互用性、依從性、安全性 ? 可靠性：成熟性、容錯性、可恢復性 ? 可用性：可理解性、易學性、可操作性 ? 效率：時間特性、資源特性

? 可維護性：可分析性、可修改性、穩定性、可測試性 ? 可移植性：適應性、易安裝性、一致性、可替換性

? 1.3.2 軟件質量管理

? 質量需求分析 ? 質量計劃 ? 質量保證 ? 質量控制 ? 質量改進

? 軟件質量管理體系

? ? ? ? ? ? ? ? ? ?

? ?

? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

1.4軟件配置管理

? 1.4.1 軟件配置項與基線

計算機軟件配置項（CSCI）基線（baseline）

功能基線（functional baseline）指派基線（allocated baseline）產品基線（product baseline）

? 1.4.2 軟件配置管理過程

對象標識 版本控制 變化控制 配置審計 配置報告

1.5軟件過程管理

? 1.5.1 軟件能力成熟度模型（CMM）

CMM的5個等級：初始級、可重復級、已定義級、已管理級、優化級 CMM的關鍵過程域（KPA）：需求管理、軟件項目計劃、軟件項目跟蹤和監控、軟件子合同管理、軟件質量保證、軟件配置管理、組織級過程焦點、組織級過程定義、培訓大綱、集成軟件管理、軟件產品工程、組間協調、同行評審、定量過程管理、軟件質量管理、缺陷預防、技術變更管理、過程變更管理

? 1.5.2 軟件過程與軟件能力成熟度評估

第一步，建立評估組 第二步，填寫提問單 第三步，響應分析 第四步，現場考察

第五步，提出調查發現清單

第六步，制作關鍵過程域（KPA）剖面圖

? 1.5.3 軟件過程改進

第一步，比較“目標狀態”與“目前狀態”，找出所有差距 第二步，確定改進目標 第三步，制定改進計劃 第四步，執行改進計劃

第五步，總結本輪改進經驗，開始下一輪改進

1.6

小節

軟件工程學是研究如何有效地組織和管理軟件開發的工程學科。

軟件產品所要經歷的計劃、分析、設計、編程、測試、維護直至被淘汰這樣一個全過程被稱為軟件生存周期。用不同的方式將軟件生命周期中的所有開發活動組織起來，可以形成不同的軟件開發模型。

軟件質量就是軟件與明確地和隱含地定義的需求相一致的程度。軟件質量管理是指軟件開發機構為保證軟件項目滿足客戶需求所要實施的質量活動。軟件配置管理是在軟件的整個生命期內管理變化的一組活動，目標是使變化更正確且更容易被適應。

軟件過程是指人們用于開發和維護軟件及其相關產品的一系列活動，包括軟件工程過程和軟件管理過程。軟件過程管理的目的就是提升軟件組織的提高軟件開發能力。

? 1.? 1.? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

第2章

項目管理基礎知識 2.1項目與項目管理 ? 2.1.1 項目

項目是在特定條件下、具有特定目標的一次性任務，是在一定時間內、滿足一系列特定目標的多項相關工作的總和。項目的臨時性 項目的獨特性 項目的漸進性

2.1.2 項目管理

項目管理就是將各種知識、技能、工具和技術應用于項目之中，以達到項目的要求。項目范圍 項目時間 項目成本 項目質量

2.2項目管理過程與過程組 ? 2.2.1 過程與過程組

過程就是一組為了完成一系列事先指定的產品、服務或成果而需執行的互相聯系的行動和活動。軟件項目管理過程可歸納為五個過程組。啟動過程組（initiating process group）規劃過程組（planning process group）實施過程組（executing process group）

監控過程組（monitoring and controlling process group）收尾過程組（closing process group）

? 2.2.2 項目管理過程的交互作用

項目管理過程并不是互不相干的一次性事件

項目管理過程組之間是一種前后銜接、承前啟后的關系

項目管理過程組之間有時又是一種時間交錯、空間并行的關系 項目管理過程組之間還是一種信息收集、存儲、處理和傳遞的關系 某些過程組的關聯具有重復迭代性

規劃過程組、執行過程組和監控過程組之間形成一種閉環的關系 過程組的交互作用往往還會跨越項目階段 項目階段和過程之間有相互聯系

? 2.2.3 項目管理過程的裁剪

不同類型的軟件項目應選用不同的項目管理過程 不同階段的軟件項目應選用不同的項目管理過程 不同軟件項目的管理過程會有不同的具體過程 不同軟件項目的管理過程會有不同的具體過程順序 不同軟件項目的管理過程會有不同的條件與約束 不同軟件項目的管理過程會有不同的簡化程度 不同軟件項目的管理過程需要不同的集成程度 項目變更會使項目管理過程隨之變化

2.3項目管理知識體系

項目綜合管理 項目范圍管理

? ? ? ? ? ? ? ? ? ? 項目時間管理 項目成本管理 項目質量管理 項目人力資源管理 項目溝通管理 項目風險管理 項目采購管理

2.4小節

項目管理就是將項目管理知識、技能、工具和技術應用于項目活動之中，可以將軟件項目管理活動視做一系列相互聯系的過程。

項目管理過程可歸納為5個過程組：啟動過程組、規劃過程組、實施過程組、監控過程組與收尾過程組。

項目管理包括9個知識領域：項目綜合管理、項目范圍管理、項目時間管理、項目成本管理、項目質量管理、項目人力資源管理、項目溝通管理、項目風險管理與項目采購管理。

第3章

軟件開發技術 3.1軟件開發平臺

? 3.1.1 Microsoft.NET平臺

Microsoft.NET Framework：.NET CLR（通用語言運行環境）；.NET BCL（基礎類庫）；ASP.NET；ADO.NET。

Microsoft Visual Studio.NET：ADO.NET組件；XML數據組件；Windows表單組件；ASP.NET應用服務；ASP.NET Web表單；Web服務支持。

? 3.1.2 J2EE平臺

組件-容器：搭建體系架構平臺標準服務 多層應用模型

3.1.3 Microsoft.NET與J2EE的異同

類似的平臺基礎構造 相同的三層/多層體系 不同的移植、性能和擴展 在Web支持方面的比較 第三方廠商的支持 潛在的市場

3.2中間件技術 ? 3.2.1 中間件簡介

終端仿真/屏幕轉換中間件 數據訪問中間件 遠程過程調用中間件 消息中間件 交易中間件 對象中間件

Web服務器中間件 安全中間件

? 3.2.2 消息代理中間件 ? ?

? ? ? ? ? 1.? ? 1.? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

?

? 構件化的結構

可恢復性、易于管理、靈活性 具有數據轉換設施。可靠高效的通信 多樣的管理能力 豐富的應用開發環境

? 3.2.3 面向數據庫的中間件

ODBC JDBC 數據庫網關

3.3構件技術 ? 3.3.1 構件庫

構件的存儲

構件的分類與檢索機制 構件庫的編目

構件庫的管理和維護

? 3.3.2 構件模型

3C模型

刻面（Facet）模型 青鳥模型

? 3.3.3 構件的屬性與特點

構件是可獨立配置的單元，構件必須自包容。

構件強調與環境和其他構件的分離，因此構件的實現是嚴格封裝的，外界沒機會或沒必要知道構件內部的實現細節。

構件可以在適當的環境中被復合使用，因此構件需要提供清楚的接口規范，可以與環境交互。

構件沒有個體特有的屬性，最多僅有特定構件的一份副本。

? 3.3.4 構件與中間件

中間件，本質上是對分布式應用的抽象，中間件與系統架構實際上是從兩種不同的角度看待軟件的中間層次。

中間件促進了構件化軟件，基于中間件開發的應用系統是構件化的，中間件提供了構件的體系結構，極大提高了構件化軟件開發的效率和質量。構件化的軟件設計思想在中間件發展中起到了重要的作用。

3.4小節

Microsoft.NET平臺和J2EE平臺是目前最常用的兩大軟件開發平臺。作為彼此競爭的應用平臺，Microsoft.NET平臺和J2EE平臺在目標和體系結構上極其相似，但在實現上又完全不同。二者總的關系是：異中有同，同中有異。中間件是處于操作系統和應用程序之間的軟件。中間件保持了平臺的透明性，抽象了典型的應用模式。應用軟件開發者可以基于標準的中間件進行再開發，而不必再考慮操作系統的問題。

構件是可復用的軟件成份，可被用來構造其他軟件。中間件促進了構件化軟件，應用系統在中間件提供的環境中可以更好地集中于業務邏輯上，并以構件的形式存在。構件思想也反過來推動了中間件的發展。

第4章

軟件項目規劃

4.1項目策劃

? 1.? 1.從政策導向中尋找項目機會 從市場需求中尋找項目機會 從技術發展中尋找項目機會 從特定事件中尋找項目機會

4.2項目可行性分析 4.2.1 技術可行性分析

? ? ? ? ? 1.? ? ? ? ? ? ? ? ? 項目的必要性分析

軟件組織水平與能力分析 項目技術來源分析 與項目相關的專利分析

項目負責人及技術骨干的資質分析 項目總體技術方案分析 項目創新點分析 項目技術風險分析 項目技術成熟性分析

? 4.2.2 項目投資及效益分析

項目投資預算分析 項目投資來源分析

市場需求與產品銷售額分析

產品成本、利潤與盈虧平衡點分析 投資回收期、投資收益率分析 社會效益分析

4.3項目論證、評估與立項

? 4.3.1 項目論證與評估的基本概念

項目論證是指對擬實施項目技術上的先進性、成熟性、適用性，經濟上的合理性、盈利性，實施上的可能性、風險性進行全面科學的綜合分析，為項目決策提供客觀依據的一種技術經濟研究活動。

項目評估指在項目可行性研究的基礎上，項目投資者或項目主管部門或其委托的第三方權威機構根據國家頒布的政策、法律、法規、標準和技術規范，對擬開發項目的市場需求、技術先進性和成熟性、預期經濟效益和社會效益等進行評價、分析和論證，進而判斷其是否可行的過程。

項目論證與評估的內容、程序和依據大同小異，只是側重點稍有不同，有時不加區分或合并進行。

? 4.3.2 項目可行性報告的真實性評估

項目申請單位的資質真實性評估 項目申請單位的財務真實性評估 項目申請單位的技術真實性評估 其他事項的真實性評估

? 4.3.3 項目可行性報告的客觀性評估

技術創新點的客觀性評估

技術先進性與成熟性的客觀性評估 ?

?

?

? ? ? ? ? ?

? ? ? ? 信息安全措施的客觀性評估

采用標準、規范的先進性、合理性評估 項目風險及應對方案的客觀性評估 其他事項的客觀性評估

? 4.3.4 評估報告

? 項目概況 ? 評估目標 ? 評估依據 ? 評估內容

? 評估機構與評估專家 ? 評估過程

? 詳細評估意見

? 存在或遺漏的重大問題 ? 潛在的風險 ? 評估結論

? 進一步的建議

? 4.3.5 項目立項

項目立項的決定應當由項目團隊之外的、適當級別的、并為項目出資的項目發起人或投資人作出，通常以項目立項決定（通知）書、項目批文、項目許可證書和項目任務書等形式發布。

4.4項目開發計劃

? 1．引言 ? 2．引用文件 ? 3．項目最終成果 ? 4．需求與約束

? 5．系統開發總體計劃 ? 6．項目開發詳細計劃 ? 7．進度表與活動網絡圖 ? 8．項目組織與資源 ? 9．培訓

? 10．項目估算 ? 11．風險管理 ? 12．支持條件 ? 13．注解 ? 14．附錄

4.5小節

? 軟件項目規劃的任務主要包括項目策劃、可行性研究、論證、評估、立項與項目開發計劃的制訂工作。

? 項目策劃，也稱項目機會研究，其目的是選擇投資機會、鑒別投資方向。

? 項目可行性分析的目的是確定以下問題：項目有無必要？能否完成？是否值得去做？ ? 項目論證與評估的目的是審查項目可行性研究的可靠性、真實性和客觀性，為項目主管部門或投資機構的立項決策提供科學依據。

? 項目開發計劃是項目規劃階段的重要成果，編寫軟件項目開發計劃時可依據《GB/T 8567-2006 計算機軟件文檔編制規范》中的軟件開發計劃模版。

? ?

? ? ? ? ?

?

?

?

?

? ? ? ? ? ? ? ? ?

第5章

系統分析方法學 5.1系統需求分析與軟件需求

系統需求：系統總體功能和業務結構；硬件系統需求；軟件系統需求；硬件系統和軟件系統之間的接口需求。軟件需求：軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求。

5.2結構化分析

結構化分析（SA）方法是一種面向數據流的需求分析方法，基本思想是自頂向下逐層分解。

數據流圖（DFD）和數據字典（DD）是結構化分析最常用的工具。數據流圖用來描述數據流從輸入到輸出的變換流程。

數據字典是關于數據的信息的集合，也就是對數據流圖中包含的所有元素的定義的集合。

數據流圖和數據字典共同構成系統的邏輯模型。

5.3原型化方法

? 5.3.1 原型化方法與結構化方法的比較

結構化方法的假設：所有的需求都能被預先定義；修改定義不完備的系統代價昂貴且實施困難；項目參加者之間能夠清晰進行準確的通信；靜態描述或圖形模型對應用系統的反映是充分的；結構化方法的生命周期的各階段都是固有正確的。

原型化方法的假設：并非所有的需求在系統開發以前都能準確地說明；有快速的系統建造工具；項目參加者之間通常都存在通信上的障礙；需要實際的、可供用戶參與的系統模型；需求一旦確定，就可以遵從嚴格的方法；大量的反復是不可避免的、必要的，應該加以鼓勵。

? 5.3.2 原型生命周期及其策略

原型生命周期劃分：選擇開發方法；識別基本需求；開發工作模型；模型驗證；修正和改進；判定原型完成；差別細部說明；嚴格說明細部；判定原型效果；整理原型和提供文檔。

原型化的策略：建立數據模型；利用組合工程；剪裁和粘貼；用系統舉例；字典驅動；文檔的自動化；小的原型化隊伍；交互式開發平臺；陳述性規格說明；終端用戶報表生成器；專業原型化人員；開發人員參加原型化。

5.4面向對象的分析

? 5.4.1 面向對象方法學概述

對象與封裝 類

繼承與多態性 消息通信

面向對象方法學的優點

? 5.4.2 面向對象的分析方法

OMT方法簡介 建立對象模型 建立動態模型 建立功能模型

?

?

? ? ?

? ? ? ? ? ? ? 1.? ? 1.? ? ? ? ?

? ? ? ? ? ?

5.5小節

系統分析涉及系統需求的獲取、分析、規格說明和確認。系統需求可分為以下幾個方面：系統總體功能和業務結構、硬件系統需求、軟件系統需求、硬件系統和軟件系統之間的接口需求。

常用的系統分析方法包括結構化分析、原型化方法和面向對象的分析。

第7章

系統分析文檔

7.1系統/子系統需求規格說明

引言 引用文件

需求：要求的狀態和方式；需求概述；系統能力需求；系統外部接口需求；系統內部接口需求；系統內部數據需求；適應性需求；安全性需求；保密性和私密性需求；操作需求；可使用性、可維護性、可移植性、可靠性和安全性需求；故障處理需求；系統環境需求；計算機資源需求；系統質量需求；設計和構造的約束；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 非技術性需求 尚未解決的問題 注解 附錄

7.2接口需求規格說明

引言 引用文件 需求

合格性規定 需求可追蹤性 注解 附錄

7.3軟件需求規格說明

引言 引用文件

軟件需求：要求的狀態和方式；需求概述；需求規格；軟件能力需求；軟件外部接口需求；軟件內部接口需求；軟件內部數據需求；適應性需求；安全性需求；保密性和私密性需求；軟件環境需求；計算機資源需求；軟件質量需求；設計和實現的約束；數據需求；操作需求；故障處理需求；算法需求；相關人員需求；相關培訓需求；相關后勤需求；包裝需求；其他需求；需求的優先次序和關鍵程度 合格性規定 需求可追蹤性 尚未解決的問題 注解 附錄

7.4小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》（Specification for computer

? ? ?

? ?

? ? ? ? ? ?

? ? ? ? ?

?

? software documentation），系統分析文檔主要包括系統/子系統需求規格說明（SSS）、接口需求規格說明（IRS）和軟件需求規格說明（SRS）。系統/子系統需求規格說明（SSS）為一個系統或子系統指定需求以及保證每個需求得到確認所使用的方法。

接口需求規格說明（IRS）描述為實現一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶

軟件需求規格說明（SRS）描述對計算機軟件的需求以及確保每個需求得到確認所使用的方法。

第8章

系統設計基礎 8.1系統設計概述

? 8.1.1 系統級設計決策

系統級設計決策，是指系統行為的設計決策（忽略其內部實現，從用戶角度出發，描述系統將怎樣運轉以滿足需求）和其他對系統部件的選擇和設計產生影響的的決策。系統級設計決策內容：有關系統接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的系統行為的設計決策；系統數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；硬件或硬軟件系統的設計和構造選擇；為了響應需求而作出的其他系統級設計決策。

? 8.1.2 系統架構設計

總體設計

系統部件設計 動態交互設計 接口設計

? 8.1.3 運行設計

系統初始化——說明本系統的初始化過程。

運行控制——說明對系統施加不同的外界運行控制時所引起的各種不同的運行組件組合、每種運行所經歷的內部組件和支持軟件、每一種外界運行控制的方式方法和操作步驟、每種運行組件組合將占用各種資源的情況以及系統運行時的安全控制。運行結束——說明本系統運行的結束過程。

? 8.1.4 系統出錯處理設計

出錯信息——包括出錯信息表、故障處理技術等。補救措施——說明故障出現后可能采取的補救措施。

? 8.1.5 系統維護設計

檢測點的設計——說明在系統中專門安排用于系統檢查與維護的檢測點。

檢測專用組件的設計——說明在系統中專門安排用于系統檢查與維護的專用組件。

8.2軟件設計概述

? 8.2.1 軟件級設計決策

軟件級設計決策是指軟件行為的設計決策（忽略其內部實現，從用戶角度出發，描述軟件將怎樣運轉以滿足需求）和其他影響組成該軟件的軟件配置項的選擇與設計的決策。

軟件級設計決策內容：有關軟件接收的輸入和產生的輸出的設計決策；對每個輸入或條件進行響應的軟件行為的設計決策；有關數據庫/數據文件如何呈現給用戶的設計決策；為滿足安全性、保密性和私密性需求所選用的方法；為響應需求而作出的其他軟件級設計決策。

? 8.2.2 軟件架構設計

? ? ? ? ? ? ? ? ? ? ? 程序結構設計

全局數據結構設計 軟件配置項設計 動態交互設計 接口設計

? 8.2.3 軟件詳細設計

軟件配置項設計決策

軟件配置項設計中的約束、限制或非常規特征 軟件配置項使用的編程語言考慮 軟件配置項使用的過程式命令選取

軟件配置項的局部數據與軟件配置項的輸入或輸出數據設計 軟件配置項的邏輯設計

8.3設計原則 ? 8.3.1 組件化

組件的可分解性 組件的可組裝性 組件的可理解性 組件的連續性 組件的保護性

? 8.3.2 抽象

抽象就是抽出事物的本質特性而暫時忽略其細節，使得不同的事物可以當作相同的事務來處理。

軟件工程過程的每一步都是對軟件解法的抽象層次的一次精化。

軟件設計中的抽象機制主要包括類、模板、過程抽象、數據抽象和控制抽象。

? 8.3.3 內聚與耦合

內聚是指一個組件內各個元素彼此結合的緊密程度 內聚種類（由低到高排列）：偶然內聚；邏輯內聚；瞬時內聚；過程內聚；通信內聚；順序內聚；功能內聚

耦合是指一個軟件結構內不同組件之間的互連程度 耦合種類（由高到低排列）：內容耦合；公共耦合；外部耦合；控制耦合；標記耦合；數據耦合；非直接耦合

組件的高內聚、低耦合原則稱為組件獨立原則

? 8.3.4 封裝與信息隱蔽

第一，組件是其全部屬性和全部服務緊密結合而形成的一個不可分割的整體。

第二，組件是一個不透明的黑盒子，表示組件狀態的數據和實現操作的代碼都被封裝在黑盒子里面。使用一個組件的時候，只需知道它向外界提供的接口形式，無須知道它的數據結構細節和實現操作的算法。

? 8.3.5 啟發式規則

深度、寬度、扇出與扇入 作用域和控制域 功能的可預測性

8.4設計視圖

? 8.4.1 架構視圖（靜態視圖）

架構描述語言（ADL）? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? ?

?

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ?

? ? 類圖與對象圖 組件圖

協作責任卡（CRC）部署圖

實體-聯系圖（E-R圖）接口描述語言（IDL）結構圖

Jackson結構圖

? 8.4.2 行為視圖（動態視圖）

活動圖 協作圖 順序圖 數據流圖

決策表和決策圖

流程圖和結構化流程圖 狀態圖

形式化描述語言 偽碼

8.5小節

系統設計是定義一個系統或軟件的架構、組件、接口和其它特征的過程。包括系統級設計決策、系統架構設計、運行設計、系統出錯處理設計和系統維護設計。

軟件設計主要包括軟件級設計決策、軟件架構設計（概要設計）與詳細設計。軟件架構設計的主要任務是程序結構設計、全局數據結構設計、軟件配置項設計、動態交互設計和接口設計。軟件詳細設計是指每一個軟件配置項的具體設計。

組件化、抽象、高內聚與低耦和、封裝與信息隱蔽是軟件設計的基本原則。軟件設計視圖通常可分為架構視圖（靜態視圖）和行為視圖（動態視圖）兩類。第9章

系統設計方法 9.1結構化設計

? 9.1.1 結構化設計方法概述

分析系統的總體需求，并將需求逐步分解為基本、具體的功能。確定每個功能應當記錄的數據。

列出系統中應提供的各項基本功能，并分析各項基本功能之間的耦合關系，根據高內聚、低耦和的原則分配到系統中適當的模塊中。

? 9.1.2 系統結構圖

模塊 調用 數據 控制 轉接符號

? 9.1.3 系統結構圖分類

變換流與事務流 變換型系統結構圖 事務型系統結構圖 ? ? ?

? ? ? ? ? ? ? ?

? 混合型系統結構圖

9.2面向數據結構的設計

? 9.2.1 面向數據結構的設計概述

分析并建立適合系統的數據結構；

根據數據結構在相應的層次建立程序結構；

羅列出程序中用到的各種基本操作，并將這些基本操作分配到程序結構中合適的模塊中。

? 9.2.2 Jackson圖

順序結構 選擇結構 重復結構

改進的Jackson圖

? 9.2.3 Jackson方法

分析并確定輸入和輸出數據的邏輯結構，并利用Jackson 找出輸入和輸出數據結構中存在對應關系的數據單元。從描繪數據結構的Jackson圖導出描繪程序結構的Jackson

列出所有操作和條件(包括分支條件和循環結束條件)，并且把它們安排到程序結構圖的適當位置。用偽代碼表示。

9.3面向對象的設計

? 9.3.1 面向對象的設計概述

面向對象設計的基本思想是通過建立和客觀實際相對應的對象，并通過這些對象的組合來創建具體的應用。

面向對象設計具有基于抽象、信息隱藏、功能獨立和模塊性構造系統的能力。

對于面向對象的系統，可以定義一個四個層次的設計金字塔：子系統層；類及對象層；消息層；責任層。

? 9.3.2 面向對象設計技術

? Coad/Yourdon方法 ? Booch方法 ? OMT方法 ? ?

? 9.3.3 面向對象設計過程

系統設計過程：將分析模型劃分為子系統；子系統分配及與問題的并發性；任務管理；數據管理；資源管理；人機界面；子系統間通信

對象設計過程：對象描述；算法與數據結構設計；接口設計與模塊化

9.4設計模式

? 9.4.1 設計模式概述

設計模式就是將面向對象軟件的設計經驗記錄下，可供設計者能夠復用的設計方案。設計模式極大提高了面向對象軟件開發的效率，降低了軟件的復雜度。

在軟件設計中使用設計模式，將使用開發出來的軟件更容易理解、更容易維護、更容易擴展，使用設計模式同時也能夠提高開發團隊和個人的開發能力。

? 9.4.2 設計模式基本組成

模式名稱：惟一標識一個設計模式。問題：描述應該在何時使用該模式。? ? ?

? ? ? ? ? ? ? ? ?

? ? ?

? ? ?

? ?

? 解決方案：描述設計的組成要素，以及它們之間的相互關系及各自的職責與相互之間協作的方式。

? 效果：描述應用設計模式的效果，以及使用設計模式必須考慮的限制和約束因素。

? 9.4.3 設計模式分類

? 面向對象模式 ? 代碼模式

? 框架應用模式

? 創建型模式、結構型模式與行為型模式 ? 類模式與對象模式

? 9.4.4 如何使用設計模式

? 針對接口編程，而不是針對實現編程 ? 優先使用對象組合，而不是類繼承 ? 找出變化并封裝

9.5小節

? 系統設計是一系列迭代的過程，主要任務包括數據結構、體系結構、接口及過程細節的設計等，而設計方法是軟件設計活動中實現設計模型的方法。? 系統設計方法主要包括面向過程的結構化設計方法、面向數據結構的設計，以及面向對象的設計方法與設計模式。

第10章

數據庫設計 10.1數據建模

? 10.1.1 數據模型分類

? 概念數據模型 ? 結構數據模型 ? 物理數據模型

? 10.1.2 實體-聯系（E-R）模型

? 實體 ? 屬性 ? 聯系 ? 實體型 ? 實體集 ? 鍵 ? 域

? 10.1.3 數據模型

? 層次數據模型（hierarchical model）? 網狀數據模型（network model）? 關系數據模型（relational model）

? 面向對象模型（object oriented model）

10.2數據規范化

? 10.2.1 數據規范化的基本概念

? 函數依賴

? 非平凡函數依賴 ? 完全函數依賴 ? 部分函數依賴

? 傳遞函數依賴 ? 鍵

? 10.2.2 范式

? ? ? ? 第一范式（1NF）第二范式（2NF）第三范式（3NF）BC范式（BCNF）

10.3數據庫設計過程 ? 10.3.1 數據庫需求分析

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 數據邊界的確定 數據環境的確定 數據內部關系 數據字典

數據性能需求

數據需求分析說明書

? 10.3.2 數據庫概念設計

概念設計與概念模型 概念設計的主要方法 分解與抽象 局部概念模式 全局概念模式

? 10.3.3 數據庫邏輯設計

初始模式的形成 子模式設計

應用程序概要設計 模式評審 修正模式

? 10.3.4 數據庫物理設計

存儲記錄結構設計 確定數據存放位置 存取方法設計

完整性和安全考慮 程序設計

10.4小節

? 數據庫系統普遍采取數據模型表示和處理客觀事物的數據特征與信息。數據模型主要由數據結構、數據操作和完整性約束三部分組成，從抽象層次上描述和模擬了系統的靜態特征、動態行為和約束條件。

? 關系數據庫中的關系必須滿足一定的要求，即滿足不同的范式。目前關系數據庫中常用的范式包括：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）和BCNF。? 數據庫設計主要包括需求分析、概念設計、邏輯設計和物理設計等幾個階段。

第11章

用戶界面設計

11.1基本概念

? ? ?

? ? ? ? ? ? ? ? ? ?

? ? ? ? ? ?

? ? ? ? ? ? ? ? ? ? ? ?

? 11.1.1 界面設計目標

可用性目標：可行性、有效性、易學性、易記性、安全性、通用性

用戶體驗目標：令人滿意、令人愉快、引人入勝、富有啟發、激發創造??

可用性目標主要從客觀角度來評價系統界面，而用戶體驗目標則是從用戶主觀感受的角度來評價系統界面。

? 11.1.2 界面設計原則

可視性：將系統功能呈現得一目了然。

反饋性：返回與活動相關的信息，以便用戶能夠繼續這個活動。限制性：將用戶的行為限制在一定的范圍內。

對應性：明確系統某個控制與其控制效果之間的對應關系。一致性：用相似的元素表現相似的操作或相似的任務。啟示性：界面元素應給予用戶某種提示。

? 11.1.3 界面設計過程

標識出用戶的真實需要并建立需求模型 設計出候選方案

構建或實現設計的原型版本 對界面設計進行評估

11.2界面設計技術

? 11.2.1 界面設計分析技術

GOMS模型及GOMS擊鍵層模型 Hick律 Fitts律

? 11.2.2 界面設計方法

原型設計方法

以用戶為中心的設計方法 用戶界面設計的支持工具

11.3界面設計評估

? 11.3.1 構造性評估與總結性評估

構造性評估：在設計過程中對所設計的系統或產品界面進行評估以確保其滿足用戶需求。

總結性評估：對已經完成的產品或系統界面進行評估。

? 11.3.2 評估范型

快速評估 可用性測試 實地研究 預測性評估

? 11.3.3 評估方法與技術

觀察用戶

征求用戶意見 征求專家意見 用戶測試

用戶執行情況的分析模型

? 11.3.4 評估框架

明確（Determine）

? ? ? ? ? ? ? ? ?

發掘（Explore）選擇（Choose）標識（Identify）決定（Decide）評估（Evalute）

11.5小節

用戶界面體現了用戶利用系統完成任務的方式以及系統對用戶行為的響應方式，一個沒有良好的用戶界面設計的系統很可能會成為一個沒有用戶的系統。可用性目標與用戶體驗目標。

界面設計的量化模型：GOMS模型及其子模型-擊鍵層模型，Hick律和Fitts律。構造性評估與總結性評估。

第12章

系統設計文檔

12.1系統/子系統（結構）設計說明

? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 引言 引用文件

系統級設計決策

系統體系結構設計：總體設計；系統部件設計；動態交互設計；接口設計 運行設計

系統出錯處理設計 系統維護設計 尚未解決的問題 需求的可追蹤性 注解 附錄

12.2

接口設計說明

引言 引用文件 接口設計

需求的可追蹤性 注解 附錄

12.3

軟件（結構）設計說明

引言 引用文件

軟件級設計決策

軟件體系結構設計：程序結構設計；全局數據結構設計；軟件配置項設計；動態交互設計；接口設計 軟件詳細設計 需求的可追蹤性 注解 附錄

12.4數據庫設計說明

? ? ? ? ? ? ? ? ?

? ? ? ? ?

引言 引用文件

數據庫級設計決策 數據庫詳細設計

用于數據庫操縱或訪問的軟件配置項的詳細設計 需求的可追蹤性 注解 附錄

12.5

小節

根據《GB/T 8567-2006 計算機軟件文檔編制規范》，系統設計文檔主要包括系統/子系統設計（結構設計）說明（SSDD）、接口設計說明（IDD）、軟件（結構）設計說明（SDD）和數據庫設計說明（DBDD）。

系統/子系統設計（結構設計）說明（SSDD）描述了系統（或子系統）的系統級（或子系統級）設計決策與體系結構設計。

接口設計說明（IDD）描述了一個或多個系統、子系統、硬件配置項（HWCI）、計算機軟件配置項（CSCI）、用戶或其他系統部件的接口特性。

軟件（結構）設計說明（SDD）描述了計算機軟件系統的軟件級設計決策、軟件體系結構設計（概要設計）與詳細設計。

數據庫（頂層）設計說明（DBDD）描述了數據庫的設計。系統設計文檔可以使用自然語言，可以使用形式化語言，也可以根據具體的系統設計方法使用各種圖形工具，還可以根據實際情況混合使用多種表現形式。