6、可視化開發方法
其實可視化開發并不能單獨的作為一種開發方法，更加貼切的說可以認為它是一種輔助工具，比如用過SYBASE的S-Design的人都知道，用這個工具可以進行顯示的圖形化的數據庫模式的建立，并可以導入到不同的數據庫中去。當然用過S-Design的人不一定很多，但用過VB，DELPHI，C++ Builder等開發工具的人一定不少，實際上你就是在使用可視化開發工具。
當然，不可否認的是，你只是在編程這個環節上用了可視化，而不是在系統分析和系統設計這個高層次上用了可視化的方法。實際上，建立系統分析和系統設計的可視化工具是一個很好的賣點，國外有很多工具都致力于這方面產品的設計。比如Business Object就是一個非常好的數據庫可視化分析工具。
可視化開發使我們把注意力集中在業務邏輯和業務流程上，用戶界面可以用可視化工具方便的構成。通過操作界面元素，諸如菜單、按鈕、對話框、編輯框、單選框、復選框、 列表框和滾動條等，由可視開發工具自動生成應用軟件。
第三章 怎樣培養軟件工程的思維與方法
作為軟件開發人員的一個通病是在項目初期的時候，就喜歡談論實現的細節，并且樂此不疲。我們更喜歡討論如何用靈活而簡短的代碼來實現一個特定的功能，而忽略了對整個系統架構的考慮。所以作為一個開發人員，尤其是一個有經驗的開發人員，應該把自己從代碼中解脫出來，更多的時候在我們的腦子里甚至暫時要放棄去考慮如何實現的問題，而從項目或產品的總體去考慮一個軟件產品。
以下是我個人的一些經驗：
1．考慮整個項目或者產品的市場前景。作為一個真正的系統分析人員，不僅要從技術的角度來考慮問題，而且還要從市場的角度去考慮問題。也就是說我們同時需要考慮我們產品的用戶群是誰，當我們產品投放到市場上的時候，是否具有生命力。比如即使我們采用最好的技術實現了一個單進程的操作系統，其市場前景也一定是不容樂觀的。
2．從用戶的角度來考慮問題。比如一些操作對于開發人員來講是非常顯而易見的問題。但是對于一般的用戶來說可能就非常難于掌握，也就是說，有時候，我們不得不在靈活性和易用性方面進行折中。另外，在功能實現上，我們也需要進行綜合考慮，盡管一些功能十分強大，但是如果用戶幾乎不怎么使用它的話，就不一定在產品的第一版的時候就推出。從用戶的角度考慮，也就是說用戶認可的才是好的，并不是開發人員覺的好才好。
3．從技術的角度考慮問題。雖然技術絕對不是唯一重要的，但是技術一定是非常重要的，是成功的必要環節。在產品設計的時候，必須考慮采用先進的技術和先進的體系結構。比如，如果可以采用多線程進行程序中各個部分并行處理的話，就最好采用多線程處理。在Windows下開發的時候，能夠把功能封裝成一個單獨的COM構件就不作成一個簡單的DLL或者是以源代碼存在的函數庫或者是對象。比如能夠在B/S結構下運行并且不影響系統功能的話就不一定要在C/S下實現。
4．合理進行模塊的分割。從多層模型角度來講，一般系統可以分成用戶層、業務層和數據庫層三部分。當然每以部分都還可以進行細分。所以在系統實現設計的時候，盡量進行各個部分的分割并建立各個部分之間進行交互的標準。并且在實際開發的時候，確實有需要的話再進行重新調整。這樣就可以保證各個部分齊頭并進，開發人員也可以各施其職。
5．人員的組織和調度。這里很重要的一點是到考慮人員的特長，有的人喜歡做界面，有的人喜歡做核心。如果有可能要根據人員的具體的情況進行具體的配置。同時要保證每一個開發人員在開發的時候首先完成需要和其他人員進行交互的部分，并且對自己的項目進度以及其他開發人員的進度有一個清晰的了解，保證不同部分的開發人員能夠經常進行交流。
6．開發過程中文檔的編寫。在開發過程中會碰到各種各樣的問題和困難，當然還有各種各樣的創意和新的思路。應該把這些東西都記錄下來并進行及時整理，對于困難和問題，如果不能短時間解決的，可以考慮采用其他的技術替代，并在事后做專門的研究。對于各種創意，可以根據進度計劃安排考慮是在本版本中實現還是在下一版本中實現。
7．充分考慮實施時可能遇到的問題。開發是一回事情，用戶真正能夠使用好它又是另外一回事情。比如在MIS系統開發中，最簡單的一個問題就是用戶如果數據輸入錯誤的時候，如何進行操作。在以流程方式工作的時候，如何讓用戶理解自己在流程中的位置和作用，如何讓用戶真正利用計算機進行協作也是成敗的關鍵。
以上是我個人的一點體會，實際上，作為一個軟件開發人員，我也喜歡看到問題就坐在計算機前面直接編碼，但是我確實認為軟件工程對于我們系統開發的指導作用是巨大的。作為軟件工程的擁戴者，下面我簡單結合自己的開發經歷介紹基于軟件工程的開發方法、編程規范和工具使用等方面的問題。
第四章 軟件開發的發展變化
國外很多項目的開發都是基于一些圖形化的東西來做的，他們的目的是盡量少寫代碼甚至不寫代碼。代碼能夠通過圖形化的方式自動生成，這樣的一個好處就是如果用戶的需求變化或者業務邏輯發生變化，我們需要做的就是對圖形表示的調整，然后重新自動生成代碼，這也就是國外開發很注重對項目的概念和邏輯分析的原因。
他們的重點是把業務規則和需求用圖形化的方式表現出來，然后通過CASE工具自動生成代碼。所以當國人還在不停的開發一個又一個的MIS工具的時候，國外已經把很多精力放到了CASE工具的制作上。
我們很多公司人員忙著寫具體業務過程的相關代碼，而國外很多都把精力放到對不同應用，不同行業的模型的建立和共性的提取上。所以，他們做出來的東西就相對具有很強的靈活性和擴展性，而我們是用戶的需求稍微有一點變化，就要忙著改代碼，甚至改體系結構。
另外，因為他們注重模型的建立，所以在建立其他應用的時候，能夠借鑒原先的模型，在高層次上做調整和優化，同時能夠有效的提取原有系統中可以被使用的部分。所以我們應該從以代碼為核心的軟件開發模式轉化到以模型為中心的、基于CASE的開發上來。
關于協作與"個人英雄主義"
社會進步的一個很明顯的現象就是社會分工越來越細，軟件的開發也不例外。為什么在軟件開發的今天已經不能出現象裘伯君這樣的軟件英雄的原因也在這里，單憑個人之力，我們也許窮盡有生之年也開發不出象Windows這樣的操作系統。
因為，當前軟件行業的壁壘無非就是兩個，一個就是以技術創新取勝，你模仿的了其中的界面，但是你沒有辦法實現其中的核心功能。結果是你只能購買其技術核心，而你作一些邊角工作。不舉別的例子，比如VB這樣的開發工具，其核心部分是它和第三方提供的COM控件或者是DLL函數庫，你所做的就是一個整合的工作。
第二個就是以細致取勝，也就是說功能很多而且做的很精致，即使技術本身不是很復雜，你真要想做出一個這樣的東西來沒有一兩年的工夫是不可能的。而真等你做出來了，它的新版本也早已經推出。真正能夠在市面上叫得想、經得起考驗得產品都是具有這兩方面的特點。
這兩方面的特點決定了你一個人絕對是不可能勝任的，也許你可以獨立的完成技術創新，但是你絕對不可能一個人實現所有這些紛繁復雜的功能。所以，這個時代需要創新的英雄，也更需要人與人之間的協作。
當今的軟件發展已經不是一個人可以包打天下的年代。軟件開發的管理、系統體系結構的設計、模塊之間的銜接、核心算法的實現、靈活界面的制定、軟件再開發接口的實現都需要專門的人來做。而把這些有效的集成顯然就需要有效的利用軟件工程的思想和方法。所以，真正的軟件英雄絕對不再是寫著別人看不懂代碼的程序員，而是整個體系結構的分析、設計、標準制定、協調人員。
第五章 我們是否需要軟件工程
有一點大家可以達成共識的就是，如果一個象Windows這樣的操作系統，不進行全面的規劃，不采用軟件工程的思想和方法，是絕對搞不出來的。
Windows的成功不在于它在進程管理和調度，文件系統、內存管理、界面設計等方面有多少成功的創新，它的成功最大的一點就是把所有的技術能夠合理的整合起來，并集中到一個Window操作系統特有的框架結構中去。
更為重要的是，Windows的每一項技術創新都能夠有效的整合到Windows框架中去，比如COM、XML等技術，通過ActiveX、DCOM等技術使Windows從桌面操作系統發展成為一個基于網絡的操作系統。
OLE2技術把整個Office中相關的軟件進行了有效的整合，顯然，這里我們可以把Office的設計和WPS的設計進行比較，客觀的講，WPS對中國用戶來說實在也是一個很好的產品。但是從整個系統設計概念上來講，Office顯然要比WPS高一個層次，它能夠把WORD，EXCEL，POWERPOINT，ACCESS有效的整合在一起，使我們所有辦公相關的文檔、圖表、數據庫、演示變成了一個一體化的東西。而且通過宏調用，用戶可以自己定制用戶界面并編制適當的模板，單是這個二次開發功能就不是WPS現在所能及項背的，當然限于當前用戶的水平還很少有人使用二次開發的功能。
從微軟產品系列可以看到軟件工程的作用，微軟的所有產品都有一個整體的框架結構，比如Office軟件，通過OLE技術進行有效的通訊和聯系。比如Visual系列開發工具，提供了相似的開發界面使用戶學會一種開發工具以后能夠很容易的學習其他的開發工具。比如SQL SERVER和ACCESS，盡管它們適用的范圍不同，但是它們表現給用戶的界面，特別是在查詢和分析上表現了高度的一致性。
更值得一提的是，因為設計結構的合理性，因為在開發前期作了很多分析和調研，考慮了擴展性和伸縮性，微軟的系列產品能夠很快的利用新的技術并采用統一的結構形式表現出來。比如當網絡成為計算機發展的主流的時候，幾乎微軟所有的工具都能夠快速的支持基于網絡的開發和應用。
相比之下，我們國內很多公司的產品很少具有連續性，往往是新的一個產品完全重起爐灶，和老的產品沒有半點關系。這就是我們在設計產品的時候，沒有很好的進行抽象和概念、邏輯設計，造成的結果是從舊的產品中提取不出一些有用的、共性的東西為后來的產品所使用。
當然，很多開發人員從心里也承認一個大的系統確實需要軟件工程的依托，但是一個小的工程項目是否就可以倉促上馬呢？答案是否定的。所謂麻雀碎小，五臟俱全。無論是大項目、還是小項目。它們作為一個項目，都需要有一個需求分析、系統結構建立、設計、編碼、測試等階段。這是任何一個項目都不可缺少的。
往往可以看到很多大公司的IT部門的人員都在不停的作各種各樣的報表，當各個部門提出一種新類型的報表的時候，就從數據庫中提取相應的數據并畫出業務人員所需要的樣式結構，很少是提供了一個通用的模板，當然提供高層API接口進行這種操作的就更少了。這樣不可避免的使開發人員陷入一些瑣碎的報表編制工作。而造成這個局面的很重要的一個原因就是沒有在系統開發的前期進行很好的調研、需求分析和系統體系結構的設計。
這里就我們開發過的一些小型軟件項目來談一些開發的總結和體會，一般來說，小型軟件項目功能比較單一，而且模塊與模塊之間的銜接不是很多，同時對開發周期要求比較短。
小項目雖然看起來比較簡單，所以很多開發人員容易犯一些錯誤，記得我們在開發一個基于Internet的有償服務系統的時候，有三個開發人員：一個負責前端界面的編寫，一個負責數據通訊協議和實現（基于TCP基礎上的應用協議），一個負責對數據庫數據的查詢、整理和提取。我們在開發的時候沒有認真地進行項目實際前途和工作量的估計。沒有認真地估計項目難度，比如對于通訊中多用戶并發訪問時的多線程問題和緩存處理問題，用戶批量請求處理的實現復雜度問題等等。三個人之間的接口也是在開發中休息的時候，口頭定義一下。結果發現有不嚴密的地方(比如在通訊服務器端是用VC編寫的，開發人員是通過stream來傳送數據的，客戶端是用Delphi編寫，在接收數據的時候發現數據不準確，后來研究發現VC利用CSocket在傳送數據流的時候對數據進行了自己定義的格式化，結果服務器端數據發送模塊只好重寫)，而且其中關于一個接口雙方的理解不同，然后又返工重新修改。最后到系統基本完成的時候沒有一份較正式的文檔。然后因為有人畢業離開這個項目，然后他編寫的模塊需要升級，新的接收的人不得不花很多時間去閱讀他的源代碼。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
