我們是否需要軟件工程[2]

我們是否需要軟件工程[2]  uml 模型

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

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

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

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

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

　　為了討論軟件運行的流程，可以采用UML的Use Case圖。在系統分析的時候需要明確應用域（application domain）的范圍，然后明確我們系統需要做什么。同時我們需要決定用什么方法來完成需求的獲取，這在很大程度上影響了需求分析的做法。

　　例如可以采用Use Case來表示用戶需求，那么從各種序列圖中選出相互交互的各個實體，就是一個個類。另外分析需要與設計過程相銜接。分析過程的內容是用對象和對象之間的關系來表示整個系統和系統的流程的，并不設計具體實現，如采用什么編程語言，在什么操作系統平臺上運行等等。這些具體實現是在設計階段來完成的。

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

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

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

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

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

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

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

原文轉自：http://www.anti-gravitydesign.com