如何做軟體系統講解

1. 如何做好軟體系統的架構設計

軟體架構設計的目的 對於外包業務類型的項目，軟體架構設計的目的與產品類型的項目有所不同，在這里主要討論外包類型項目的軟體架構設計目的。 1、為大規模開發提供基礎和規范，並提供可重用的資產，軟體系統的大規模開發，必須要有一定的基礎和遵循一定的規范，這既是軟體工程本身的要求，也是客戶的要求。架構設計的過程中可以將一些公共部分抽象提取出來，形成公共類和工具類，以達到重用的目的。 2、一定程度上縮短項目的周期，利用軟體架構提供的框架或重用組件，縮短項目開發的周期。 3、降低開發和維護的成本，大量的重用和抽象，可以提取出一些開發人員不用關心的公共部分，這樣便可以使開發人員僅僅關注於業務邏輯的實現，從而減少了很多工作量，提高了開發效率。 4、提高產品的質量，好的軟體架構設計是產品質量的保證，特別是對於客戶常常提出的非功能性需求的滿足。 軟體架構設計的原則 軟體架構設計必須遵循以下原則： 1、滿足功能性需求和非功能需求。這是一個軟體系統最基本的要求，也是架構設計時應該遵循的最基本的原則。 2、實用性原則，就像每一個軟體系統交付給用戶使用時必須實用，能解決用戶的問題一樣，架構設計也必須實用，否則就會「高來高去」或「過度設計」。 3、滿足復用的要求，最大程度的提高開發人員的工作效率。 軟體架構設計的幾種視圖 我們常常在討論架構設計該做些什麼的時候，或是在架構設計評審的會議上，會提出各種各樣的問題，例如開發人員該如何記錄Log，事務如何控制？怎樣才能提高我們的開發人員的工作效率，即在單位時間內更有品質的完成更多的功能？怎樣滿足客戶的非功能性需求？怎樣讓生產環境的平台管理人員更好的維護系統？ 上面這些問題，實際上是軟體系統的不同的干係人站在不同的角度上提出的問題，要回答上面這些問題，我們就得從不同的視角來看待軟體架構設計這項工作。 1、邏輯架構視角，從系統用戶的角度考慮問題，設計出來的軟體架構能夠滿足業務邏輯的需求，能夠處理現在越來越復雜的業務邏輯需求。 2、開發架構視角，從系統開發人員的角度來考慮問題，設計的架構要易於理解，易於開發，易於單元測試，最好做到讓開發人員可以用最少的代碼行數完成功能的開發。 3、運行架構視角，從系統運行時的質量需求考慮問題，特別關注於系統的非功能需求，客戶常常都會要求我們系統的功能畫面的最長響應時間不超過4秒，能滿足2000個用戶同時在線使用，基於角色的系統資源的安全控制等。 4、物理架構視角，關注系統安裝和部署在什麼樣的環境上，例如現在最流行的企業應用服務解決方案IBM Http Server ＋ WebSphere Application Server ＋ DB2，WebLogic + Oracle等。 5、數據架構視角，如今我們開發的各類系統，如MIS，ERP，SAP，基本上都是對各類數據的操作，把一堆不太好懂的數據展現成用戶容易看懂的數據，自動處理各類數據的運算等，所以數據的持久化是十分重要的一件事情。1、分析需求和理解業務模型（或領域建模），並選定關鍵Use case。 軟體的需求，可以分為從用戶視角和開發人員視角來看，從用戶的角度看，又可以分為功能性和非功能性需求，我們必須從不同的視角和級別去全面的認識需求並分析需求，理解業務模型。實踐表明，常常被我們忽視的非功能性需求常常會導致整個項目失敗。 理解業務需求最好的方式莫過於進行領域建模，領域建模與需求分析往往是交替穿叉進行的，領域建模主要有以下三個方面的作用： ◆探索復雜問題，弄清領域知識。Martin Fowler曾經說過，他採用面向對象方法最大的好處就是它有助於解決更為復雜的問題。領域建模本身作為輔助思維的工具，幫助我們將注意力始終保持在最為重要的業務概念及其關繫上，使我們能夠不斷深入地，系統的對需求進行分析和認識。領域建模往往是一個從模糊到清晰，從零散到系統的過程。 ◆決定功能范圍，影響可擴展性。任何模型都是對現實世界某種程序的抽象，這種抽象就會忽略某一些東西，例如忽略對象的屬性和對象間的關系，而這些忽略往往都是帶有一定的目的性的，這種忽略就決定了功能的范圍。模型揭示了各種功能背後的結構，如果說定義功能相當於「拍照片」的話，那麼領域建模就相當於「做透視」，更加關注問題領域的內在結構，相當於對問題領域進行了一定的抽象，良好的領域模型不僅能很好的支持現有的功能，而且還可以在一定程度上支持未來可能出現的新需求，體現良好的可擴展性。 ◆提供交流基礎，促進有效溝通。領域建模通常會使用UML圖作為呈現的方式，這樣為我們的溝通提供了方便。當然，有時候文字在描述某些特定領域的問題時可能更適合，可以靈活運用。 在我們公司的實際軟體開發流程中，往往領域建模缺少這一環節，這可能是在以後的工作中需要進一步提高之處。 雖然我們總是期望架構設計師能全面掌握需求，但由於時間和精力的限制，擺在我們面前的現實就是架構設計師沒有時間對所有需求進行深入分析，所以我們的策略就是「把好鋼用在刀刃上」，即把大部分時間和精力花在對決定架構最重要的關鍵需求上。在選擇關鍵需求時要注意：高優先順序的需求往往是從用戶的角度來看的，可能並不是真正的關鍵需求。在《RUP實踐者指南》一書中向我們講述了如何確定關鍵功能需求？A.作為應用程序的核心或實現了系統的主要介面的功能，B.必須被實現的功能，即如果這些功能不被實現，則開發出來的軟體就失去了價值，C.覆蓋了系統架構的一些方面，但沒有被其他重要的Use case覆蓋到的功能。 2、分別從各個視角來考慮軟體架構的方方面面。 軟體的架構設計必須考慮到各方面，根據前期工作確立的領域模型，關鍵需求，系統約束等進行設計，必須從系統用戶，開發人員，系統管理員，部署管理員，數據管理員等人員的角度去分析並解決問題。比如說，如果我們的運行架構採用Cluster方式時，就必須小心Cache和Session等的使用；如果我們的業務邏輯要求我們要操作多個資料庫時，就要考慮採用支持二階段事務提交的方式。 只有將這些方方面面的問題都考慮到了，這樣的架構設計才是完整的。至於每一個視圖中，我們應該設計到什麼細節這一問題，實際上與整個項目的過程定義有關。例如，如果我們有專門安排資料庫概要設計的活動，那我們在架構設計的過程中就可以只需要關注更高層次的資料庫特性及資料庫之間的關系，而每一張表的數據字典可以在後續的相關活動中進行設計，但如果沒有這樣的活動，那我們就要細化到每一張表的每一個欄位，以及表之間的關系。 3、解決技術面的重點問題和難題 在軟體架構設計的過程中，我們往往會需要攻克一些技術面的重點問題和難題，這完全是一項極其需要扎實的理論知識和豐富的實踐經驗支撐的工作。例如，我們如何提高整個系統的性能？如何能很好的導出極其復雜的「中國式報表」（一般比西方國家產出的報表要復雜很多，而且很多開源的BI類的框架並不能完全解決問題）？ 當遇到確實是很困難的問題，可以去網路一下或Google一下，也可以去請教公司的資深技術人員或專家，或者召開小范圍的技術專題討論會議，採用腦力激盪的方法試著找找答案，這樣才能提高工作的效率。 4、召開架構設計評審會議進行同行評審。 架構設計評審是極其重要的一環，我曾將其形容為「七種武器」中的離別鉤，就是因為在會議上，同行們可能會提很多問題或意見，而且很多意見很尖銳，所以一定要虛心接受，並做好記錄，正所謂「良葯苦口利於病，忠言逆耳利於行」。 在評審會議之前，我們要完成很多准備工作，最好是能准備一份簡明扼要的電子簡報，把最重要的問題列出來，這樣在進行評審會議時，就不會漫無目的，在會議前就將這些資料發給與會人員，請他們抽空先了解一下，在會議進行時，要學會控制會議的進度，提高會議的效率。 5、針對關鍵Use case在設計的架構上實現功能來驗證架構。 對於架構設計的驗證也是一項十分重要的工作，其驗證技術有很多種，在我們公司通常會採用Sample的形式，即XP中所說的迭代0，RUP中所說的切片。這樣做的好處是既可以從實際的產品角度出發來有效的驗證架構是否滿足要求，又可以比拋棄型原型驗證技術節省成本。 這個Sample絕不是我們在解決架構設計中的問題時拿來做實驗的一些代碼的拼湊，而是完整的實現某一關鍵Use case的符合架構設計和一系列規范的可交付的代碼及相關文檔。同時，這個Sample可以作為你在給大家講解或培訓架構時的教材，也可以作為開發人員使用此架構進行開發的藍本，甚至是只需要復制粘貼，加上簡單的修改即可。 6、交付給客戶Review。 這一環節，在很多公司可能並不存在，因為他們的軟體架構並不一定需要客戶Review，但像我們這種做服務的公司，最重要的就是客尊，落實到軟體架構設計這一活動，就是讓客戶理解並接受你的架構設計方案，同時，客戶也會起到幫你驗證架構的作用。通常，我們的架構得到客戶的認可後，便可進入大規模的開發。 在交付給客戶Review時，通常可能會以會議的形式進行Review，所以我們可以參照評審會議時好的做法來召開會議，在這里就不再冗述。軟體架構設計的常見誤區及解決辦法 1、架構設計的常常會「高來高去」。所謂高來高去，實際上就是我們的架構設計僅停留在模型階段，但也絕不是產生第一支樣常式式。 2、架構設計時常常會在某些方面過度設計（Over engineering）。為了一些根本不會發生的變化而進行一系列復雜的設計，這樣的設計就叫過度設計，往往會帶來資源的浪費並且會增加開發的工作量或難度。雖然我們必須考慮到系統的擴展性，可維護性等，但切忌過度設計。有時候或許你並不能判斷出哪些設計是過度設計，此時你可以請教你的PM，讓他站在整個項目的高度來幫你決策一下。 3、架構（Architecture）不是框架(Framework)，也不是簡單的將幾種框架或技術的組合，框架本身也是有架構的。框架一般是針對於某一方面或領域的重用性和可擴展性非常好的半成品，我們可以用一句較為經典的話來總結：框架是軟體，架構不是軟體，框架是一種特殊的軟體。我們在工作中通過將許多方面的可重用的工具類，公共類，基礎類等抽象出來，即可形成一些可重用的框架。 4、架構設計絕不是新技術展示平台，合適的技術才是對於項目有利的技術，必須考慮到開發人員的能力和維護人員的能力。作為一名架構設計師應該更多的考慮如何平衡業務需求，織織運作（主要指團隊中的協作）和技術三者的關系，而不僅僅是去關注那些技術細節。 5、架構設計的成功與否決定著系統品質的好壞，因為架構設計不好而導致交付的系統Bug過多，無法滿足客戶非功能性需求等問題，從而導致項目取消的案例時有發生。架構設計不是架構設計師一個人的事情，也不是幾天就能完成的一項工作，必須是架構設計師付出大量辛勤勞動後的成果，其成敗往往與組織、主管、項目經理的支持有著密切的關系。 關於架構設計的一點通用技巧 1、分層（Layer）規則。這里的層是指邏輯上的層次（Layer），並非指物理上的層次（Tier）。目前的絕大多數的企業級應用系統中都分為三層，即表現層，領域層和數據層。在對各層次進行劃分時，主要可以從以下幾個方面來考慮：A、每一層是一個相對獨立的部分，可以作為一個整體，無需對其它層了解；B、將層次間的依賴性降到最低，即降低耦合；C、可以從某種程度上替換掉某一層，而對其它層不會產生過多的影響；D，層次並不能封閉所有的東西，假如用戶界面上增加了一個欄位，那麼領域層就要增加一個數據域，數據層就要增加一個相應的欄位。同時，過多的分層可能會對性能造成一定的影響。 2、包（package）之間不要產生循環依賴。通常包的劃分會先按不同的邏輯層來劃分，在層的包下面再按功能來劃分。避免包間的循環依賴是一個比較通用的規則，這樣的規則一定有其存在的價值和道理，之所以這樣主要是出於以下原因：A、循環依賴會使分層失去意義；B、循環依賴會帶來許多潛在的風險，如可能會產生嵌套事務（nested transaction，JavaEE標准中並不支持這種事務）的現象，我就曾遇到過這樣的問題，在一個項目中，事務放在業務邏輯層統一控制，但由於開發人員忽視了架構中這樣的原則，在持久層調用了展現層的公用類，形成了迴圈的現象，導致了嵌套事務的發生。 3、設計模式的應用。在很多人的觀念里，提供設計模式就等同於GOF的設計模式，其實設計模式是個廣泛的概念，比如需求模式、領域模式、反模式等都屬於設計模式。模式其實是一門工具，是人們對於過去解決某一類問題的經驗總結，所以我們可以在設計活動中應用各種設計模式，但是在應用這些模式之前一定要先分析清楚問題，否則就可能出現「牛頭不對馬嘴」的現象。 成功的項目總有相似之處，失敗的項目卻各有各的失敗之處。好的軟體架構設計必定是成功項目的相似之處，我們有什麼理由不把軟體架構設計做好了？

2. 怎樣製作一個軟體呢

第一步：需求調研分析
1相關系統分析員向用戶初步了解需求，然後用word列出要開發的系統的大功能模塊，每個大功能模塊有哪些小功能模塊，對於有些需求比較明確相關的界面時，在這一步裡面可以初步定義好少量的界面。
2 系統分析員深入了解和分析需求，根據自己的經驗和需求用WORD或相關的工具再做出一份文檔系統的功能需求文檔。這次的文檔會清楚列出系統大致的大功能模塊，大功能模塊有哪些小功能模塊，並且還列出相關的界面和界面功能。
3 系統分析員向用戶再次確認需求。
第二步：概要設計
首先，開發者需要對軟體系統進行概要設計，即系統設計。概要設計需要對軟體系統的設計進行考慮，包括系統的基本處理流程、系統的組織結構、模塊劃分、功能分配、介面設計、運行設計、數據結構設計和出錯處理設計等，為軟體的詳細設計提供基礎。
第三步：詳細設計
在概要設計的基礎上，開發者需要進行軟體系統的詳細設計。在詳細設計中，描述實 現具體模塊所涉及到的主要演算法、數據結構、類的層次結構及調用關系，需要說明軟體系統各個層次中的每一個程序(每個模塊或子程序)的設計考慮，以便進行編碼和測試。應當保證軟體的需求完全分配給整個軟體。詳細設計應當足夠詳細，能夠根據詳細設計報告進行編碼。
第四步：編碼
在軟體編碼階段，開發者根據《軟體系統詳細設計報告》中對數據結構、演算法分析和模塊實現等方面的設計要求，開始具體的編寫程序工作，分別實現各模塊的功能，從而實現對目標系統的功能、性能、介面、界面等方面的要求。
第五步：測試
測試編寫好的系統。交給用戶使用，用戶使用後一個一個的確認每個功能。
第六步：軟體交付准備
在軟體測試證明軟體達到要求後，軟體開發者應向用戶提交開發的目標安裝程序、資料庫的數據字典、《用戶安裝手冊》、《用戶使用指南》、需求報告、設計報告、測試報告等雙方合同約定的產物。
《用戶安裝手冊》應詳細介紹安裝軟體對運行環境的要求、安裝軟體的定義和內容、在客戶端、伺服器端及中間件的具體安裝步驟、安裝後的系統配置。
《用戶使用指南》應包括軟體各項功能的使用流程、操作步驟、相應業務介紹、特殊提示和注意事項等方面的內容，在需要時還應舉例說明。
第七步：驗收
用戶驗收。

3. 電腦上的軟體是怎麼做出來的

軟體開發流程

先上一個軟體開發的整體流程圖，這就是大名鼎鼎的「瀑布模型（Waterfall Model）」。據說由溫斯頓·羅伊斯（Winston Royce）在1970年提出。

1、環境部署

准備伺服器，部署操作系統、軟體環境、安全軟體、FTP伺服器等。資料庫和應用可分開布置在多個伺服器，也可布置在同一伺服器。

准備網路，分為內網和外網。外網需要購買公網IP和域名。

負責人：網路管理員

2、軟體開發

包括開發語言選擇、架構設計、資料庫設計等工作，並進行編碼、編譯、測試、打包。

負責人：程序員

3、軟體部署

將程序文件上傳到伺服器，進行部署、配置，成功後即可通過客戶端訪問項目。

負責人：軟體實施

軟體開發階段

下面以java語言開發為例，簡單講講程序員是如何進行軟體開發的。

（本部分參考了「軟帝在線」公眾號、博客園「架構與我」的文章）。

1、新建java文件（或工程）

java源代碼本質上就是普通的文本文件，可以用txt等工具編輯java代碼（程序員一般採用源代碼編輯工具，如：Notepad++；或集成開發工具IDE，如：Eclipse）。txt編寫後需將文件擴展名改成java。

2、編寫代碼

以「Hello World」舉例編寫代碼：

public class HelloWorld {
public static void main(String[] args) {
System.out.println("Hello World");
}
}

該程序表示的意思是輸出Hello World這樣一段話。

3、編譯程序

Java程序之所以能做到跨平台運行，是因為Java程序運行在JVM中的，然而JVM只能夠識別位元組碼文件，而不能直接識別Java文件。所以需要先將Java文件編譯成位元組碼文件，即class文件，然後位元組碼文件才能夠在JVM中運行。

編譯文件，可以通過手動執行Dos命令javac，或直接用編譯器如Eclipse完成。

4、運行程序

可在Dos命令窗口中輸入java命令，按回車，輸出Hello World；

或在編譯器的控制台中看到輸出結果。

5、單元測試

單元測試（模塊測試）是開發者對編寫的一小段代碼，檢驗一個很小的、很明確的功能是否正確。

通常採用JUnit框架（多數java開發環境已集成）進行測試，即所謂白盒測試，叫「白盒」是因為程序員知道被測試的軟體如何（How）完成功能和完成什麼樣（What）的功能。

測試通過後，就完成了軟體開發階段，可以打包部署了。（IT售前圈）

4. 如何學習做系統

哈哈！！！
俺也不會作啊！要不俺就去微軟了

你可以去先學個軟體工程師，然後到微軟工作，然後再進入到系統開發部門，估計到時候就能懂點了

5. 軟體是什麼意思怎麼做軟體

國標中對軟體的定義為：與計算機系統操作有關的計算機程序、規程、規則，以及可能有的文件、文檔及數據。

軟體的開發流程：

1、首先系統地分析用戶的需求，然後列出要開發的系統的大功能模塊和每個大功能模塊中的小功能模塊，對於有些需求比較明確相關的界面時，在這一步裡面可以初步定義好少量的界面。

2、系統分析員深入了解和分析需求，根據自己的經驗和需求做出一份文檔系統的功能需求文檔。這次的文檔會清楚例用系統大致的大功能模塊以及大功能模塊中的小功能模塊，並且還例出相關的界面和界面功能。

3、系統分析員和用戶再次確認需求。

4、系統分析員根據確認的需求文檔所例用的界面和功能需求，用迭代的方式對每個界面或功能做系統的概要設計。

5、系統分析員把寫好的概要設計文檔給程序員，程序員根據所例出的功能一個一個的編寫。

6、測試編寫好的系統。交給用戶使用，用戶使用後一個一個的確認每個功能，然後驗收。

(5)如何做軟體系統講解擴展閱讀：

按應用范圍劃分，一般來講軟體被劃分為系統軟體、應用軟體。

1、系統軟體

系統軟體為計算機使用提供最基本的功能，可分為操作系統和系統軟體，其中操作系統是最基本的軟體。

2、應用軟體

系統軟體並不針對某一特定應用領域，而應用軟體則相反，不同的應用軟體根據用戶和所服務的領域提供不同的功能。

6. 怎樣在ppt中有趣的講解erp軟體

ERP系統根據演示的目的和客戶方參與的人員的不同，演示的方法也存在差異。
如果是效果性演示，首先介紹功能模塊，在介紹軟體的總體功能模塊時點到為止，如果是功能性演示，就要針對於客戶所關注的主要問題（在軟體演示之前，要了解客戶每個部門所需要解決的主要問題，但必須指明哪一個問題是他們特別關注的問題），提供相應的解決方案。在軟體功能性演示過程中要注意到：
工具/原料
ERP
方法/步驟
要根據事前准備的數據進行有目的的演示
根據事先准備好的數據，要做到不同的「令單」帶出不同的信息，達到不同的目的，實現客戶在不同業務情況下的需求。甚至要求知道每個「按鈕」可能帶來什麼結果。在許多ERP軟體演示過程中，往往存在「數據沒有、數據沒有做全」等問題，如果臨時做數據，一方面，可能使得客戶認為我們沒有充分的准備；另一方面，也可能分散客戶的關注點。
需要強調的是，ERP系統的軟體基礎設置部分的工作量比較大，如果在客戶那裡做整個項目的流程設置，可能會由於部分因素沒有考慮周全，而出現不必要的問題。更有甚至，現在的軟體在發展過程中，如果對軟體不熟悉，可能將軟體中存在的問題暴露給客戶，也就是出現「BUG」，使得軟體演示效果很差。
針對於客戶提出的問題，要靈活的掌握，要區別客戶提出問題的合理性與非合理性
目前客戶往往強調自身的個性，提出種種要求，可這種需求如果存在，卻會導致其他部門管理相對的薄弱。ERP軟體演示過程中，咨詢顧問要從科學管理的角度、企業整體效益角度分析，甚至其他同類企業管理的管理方法，建議如何去管理，如何去分析問題。
對於客戶提出的具體業務問題，可為其演示或解釋，但解決完之後即應進行軟體演示的主題，此類問題應注意兩點：千萬不能在小問題上與客戶糾纏，佔用過多時間；在客戶沒有提出的情況下，ERP系統廠商人員切不可自己主動提出。因為第一次演示是藝術性的，目的是簽單，此時談過多的細節問題只會有壞處不會有好處。演示過程中也要觀察用戶的反映，如對方不感興趣的地方盡量少講，或不講，對方感興趣的地方可以多講，最後做到客戶的心思，欣賞與ERP廠商軟體結合為一體。
需要強調的是，不要直接在演示的場合，直接說出客戶的管理不科學，或者這是人員素質比較差等因素導致的。對於軟體中不能直接解決的問題，但可以用變通的方法去實現的問題，咨詢顧問要能靈活的把握。對於不能解決的問題，要分析原因，並指明「並非軟體無法實現這樣的功能，關鍵的是這樣管理將會導致管理的復雜化，並且大大的增大勞動強度等」。
有效的控制演示現場
從開始軟體演示到結束整個談判過程的場面和氣氛，應由ERP廠商業務員或演示員控制，切不可讓客戶控制，因為演示之前客戶並不了解ERP廠商軟體，給其演示的目的就是要讓ERP廠商軟體給他留下一個好的第一印象，要做到這一點，整個演示的場面和氣氛得到有效控制是其基本因素。
在軟體演示之前，可以結合事先准備好的PPT文檔，講解本廠商提供ERP軟體的框架，讓客戶先熟悉大致的業務流程，並說明：如果對於軟體演示過程中存在的疑惑，在演示之後提供時間互相探討。一個功能、特點介紹之後，可稍作停頓，以增強節奏感，但停頓時間不可太長。用戶若在演示過程中打斷或問某個問題，也可以進行解答，但解答完之後即應進入下一個功能點介紹，切不可停留或扯到別的事情上去。
演示中「眼動、手動、口動」三者充分結合
為了增強演示的效果，在演示的過程中，要將「手與口」有機的結合起來，同時要利用「眼」，觀看客戶的反映，靈活快速的變動講課的內容。進一步講，「眼動」是指觀察用戶的反映以便做出下一步的決策；「手動」是指操作；「口動」是指嘴上說的就是手上動的，手上動的即是嘴上說的。三者之間密切配合，不致脫節，讓客戶感覺是在聽一場優美的演講，渾然一體、一氣呵成。
軟體演示時，應該注意只將客戶每個部門關注的主要問題的解決方案展示出來給客戶看即可，不可作詳細的操作演示。這種演示是一種藝術性的演示，其目的是為了給客戶展示ERP廠商軟體的優點，給客戶留下深刻的印象，講得太多太細不但客戶記不住，且效果不好。
需要強調的是「眼動」，目前許多咨詢顧問演示軟體的過程中往往忽視「互動」的效果，將整個軟體詳細演示了一遍，不管客戶是否接受。由於這種沒有注重客戶的反映，從而使得客戶認為軟體中存在許多他們不需要的功能，或者他們的關注點在軟體中沒有體現出來，甚至有的客戶認為這樣的產品演示是在浪費時間。
擴大客戶需求，強化軟體的其他功能
如果客戶方有高層領導參與，ERP系統軟體的演示就要在適當的功能模塊擴大客戶的需求，ERP軟體是個科學的管理工具，可以管理企業一些細化的業務。如，某一客戶零散的采購非常多，但是許多軟體廠商都建議客戶在供應商管理模塊中分別增加，以便達到管理的目的，可客戶感覺這種方案的確可行，但是工作量非常大，而且許多供應商是一次性使用，沒有必要進行維護。如果設置一個特定的供應商，將零散的采購需求業務都歸並給它，這樣管理起來既方便，又科學。
由於企業的領導層關注的點不同，對於軟體演示需要達到的效果也不同。如何轉變客戶從「ERP系統軟體是僅將手工勞動變成電腦管理」，到「ERP軟體包含科學的管理理念，可以優化企業的流程等」觀點。如果做好一次合理的軟體演示，不僅可以提高客戶對軟體的期望程度，而且可以促進軟體銷售進程。
軟體演示員的行為和信心
在ERP管理軟體演示過程中，演示人員自身的精神風貌和風度舉止、言談也是很重要的。演示人員一定要有信心，充滿精神、朝氣，要注意軟體演講過程中的種種細節，如回答問題的技巧，軟體演示的姿勢等等，並且讓這種架勢通過軟體演示進到客戶的心目中，給其留下深刻的印象。從某種角度上講，演示人員自身的精神風貌也是促成最終簽單不可忽視的因素。

7. 軟體怎樣做

軟體系統的開發是按階段進行的，一般劃分為以下階段：可行性討論；需求分析；系統設計(概要設計、詳細設計)；程序開發；編碼，單元測試；系統測試；系統維護。
軟體開發過程中要明確各階段的工作目標、實現該目標所必需的工作內容以及達到的標准。只有在上一個階段的工作完成後，才能開始下一階段的工作。

8. 想做一款手機app軟體，該怎麼下手，都需要做什麼

1、確定需求，進行詳細需求分析；
2、技術架構選型；
3、前後台UE UI設計；
4、系統設計、介面設計；
5、代碼實現；
6、測試發布；

9. 如何自己做電腦操作系統

如果你是要做U盤的系統的話，只要三步就能制定，而且還非常的穩定。現在都是用U盤來安裝系統的，做系統一定要用U盤來做。裡面都胡很多工具，你要做的，有空來我這里，我教你怎麼去做，U盤最少要2G以上的，4G的最好。

10. 如何製作系統軟體

首先文件是ISO的鏡像文件，然後放進空的CD盤，打開刻錄機NERO，選擇VCD,然後選擇將鏡像文件離開到光碟，在選擇添加文件進去，添加好後按確定，在按刻錄就可以了，刻錄好後就是系統安裝盤了。 http://v.youku.com/v_show/id_XMjUyNDE2OTY=.html 找了短視頻，自己看看吧