我們是否需要軟件工程

2019-11-17 04:40:48

字體：大中小

來源：轉載

供稿：網友

　　∮幸壞憒蠹銥梢源锍曬彩兜木褪牽綣桓魷骔indows這樣的操作系統，不進行全面的規劃，不采用軟件工程的思想和方法，是絕對搞不出來的。

　　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在傳送數據流的時候對數據進行了自己定義的格式化，結果服務器端數據發送模塊只好重寫)，而且其中關于一個接口雙方的理解不同，然后又返工重新修改。最后到系統基本完成的時候沒有一份較正式的文檔。然后因為有人畢業離開這個項目，然后他編寫的模塊需要升級，新的接收的人不得不花很多時間去閱讀他的源代碼。
　　所以在開發小項目的時候也必須要建立合理的模式：而所謂合理的模式就是軟件工程告訴我們的在開發一個項目的時候所需要的五步曲：獲取需求、需求分析、設計、編碼、測試。

　　1．理解用戶真正的需求。在進入正式開發之前，必須先從用戶處獲取準確的需求。在這上面花費相當時間是很必要的。

　　我們軟件項目可以大致分為專用軟件和通用軟件兩大類。對于專用軟件，一般用戶對于軟件要完成哪些功能已經有了一個比較清楚的輪廓，而且往往在開發合同中已經大致地規定了。

　　但是，開發合同上規定的只是一個大概的框架，在進入開發之前必須與用戶進行比較具體的交流和討論，了解清楚用戶心目中的產品究竟是什么樣子，這里最好就采用原型化的方法作出一個簡單的框架給用戶看。

　　對于通用軟件，在開發之前必須做一定的市場調查工作，一方面是從經濟效益考慮，調查產品的潛在市場有多大，一方面是從技術的角度，了解清楚潛在用戶對軟件的各種技術上的要求，另一方面是確定我們軟件的定位，即我們軟件具體是為哪一些用戶群體服務的。然后對該群體用戶現有硬件配置，軟件配置，網絡使用情況，數據庫使用情況，計算機熟悉程度做一定的調研，根據調查的統計結果決定即將開發的軟件的一些技術指標。
　　
　　2．需求分析。需求分析需要做的事情有：高層構思、確立系統目標、劃分業務領域、現行業務分析、建立業務模型(EnterPRise Model)、信息需求分析、用戶視圖規范化、數據元素標準化與一致性控制。

　　在了解用戶的需求之后，將需求用一種模型來表示，就是需求分析，一般我們可以面向對象的方法，通過分析用戶需求，用類、類之間的各種關系來表示整個系統。

　　為了討論軟件運行的流程，可以采用UML的Use Case圖。在系統分析的時候需要明確應用域（application domain）的范圍，然后明確我們系統需要做什么。同時我們需要決定用什么方法來完成需求的獲取，這在很大程度上影響了需求分析的做法。
　　例如可以采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。另外分析需要與設計過程相銜接。

分析過程的內容是用對象和對象之間的關系來表示整個系統和系統的流程的，并不設計具體實現，如采用什么編程語言，在什么操作系統平臺上運行等等。這些具體實現是在設計階段來完成的。

　　面向對象方法的優點是分析、設計、編碼過程表示法統一，能比較好的銜接。現在很多CASE工具并不區分分析和設計的階段。但是，這并不意味著開發就可以對分析和設計不加區分，如何用好輔助設計(case)工具還是開發人員的事情。

　　3．設計過程。設計階段的工作包括對分析模型進行必要的修改，同時可能需要對某些類結構做一些修改，確定用戶表示層(也就是通俗所說的界面定義)、用戶服務層、業務邏輯層、數據庫服務層和具體數據庫所需要做的工作。同時需要確定使用的體系結構（比如B/S還是C/S）和開發工具（如VB，VC，VI，C++ Builder，DELPHI，PowerBuiler等等）

　　4．編碼。進入編碼工作之后，依然可能會發現前面分析或設計階段的某些錯誤，這時應返回到前面的階段進行必要的修改。同時在編碼前規定編碼的風格并在開發過程中保持一致的風格。

　　5．測試。測試是系統投入使用前最要害的一個步驟。即使是小項目也應該嚴格地進行測試。就實際上就是一個把錯誤留給自己還是留給客戶的問題。

　　最后，我們知道軟件項目主要是由開發人員完成的，所以對人員的合理安排和配置也很重要，一般在開發過程中，需要有一位項目負責人，負責分析、設計和協調的工作。另外需要幾個程序員完成不同層的代碼（比如用戶服務層、業務邏輯層、數據庫服務層等等）。

　　同時需要有一個文檔整理人員隨時整理系統開發過程中相關的文檔。假如條件可能的話，要配置一個測試工程師，專門進行代碼的測試工作，當然假如條件不答應的話，也可以由開發人員交叉測試。這里需要注重的是，對于項目負責人而言，協調幾個人的工作比自己完成一段編碼更重要。

　　由于協調上出了漏洞，可能導致很大的問題，所以項目負責人必須隨時監控各開發人員的工作，包括內容是否與要求發生偏差，進度是否滯后等等。同時必須給每個開發人員明確的任務書。具體開發時每個開發人員必須非常明確自己的任務，這些任務應該采用明確的文檔來表示。每個開發人員需要清楚自己所做的工作在整個系統中處于什么地位，這樣就有可能會發現設計模型中的漏洞，避免了各人的代碼編寫完畢之后又要修改的后果。

上一篇：用Winsock實現點對點通信

下一篇：測試ActiveX EXE