想和大家一起來談談在軟件工程中我們所做的第一步:系統分析。希望我們中國的代碼人能吸取更多更好的理論和實際的經驗,有符合我們實際情況的系統分析、開發方法、步驟以及文檔。系統分析,我個人認為它應該是能體現系統的靈魂性的文檔。該文檔應有什么內容,表達什么意思是我想在這里與大家探討的問題。我覺得在系統分析書中應該有以下內容(視項目而定)
1、 系統需求說明 說明系統是一個什么樣的系統,用市場上現有的系統來類比,用客戶(或是我們自己)需要一個什么樣的系統進行說明,力求完整。并對系統的發展可擴充性進行描述(現在沒有哪個系統是一次OK的)。說明與現有的系統有什么相同什么不同,說明未來系統的發展方面以及可移值性等能預見的事情。
2、 系統資源說明 對系統所需要的軟件、硬件資源進行說明。描述系統所需要的所有的TCO成本。包括人員、時間、設備、系統、一次性投入資金、持續性投入資金這樣的所有資源。
3、 系統可行性分析 對系統的實施中的資源進行分析,說明投入的合理性和必然性,對其中的所有不可預見性的投入進行合理的量化說明,來說明系統的實施的可行性。
以上為我所想到的系統分析說明書中應出現的前三種文檔,不知大家有什么想法,請賜教。
作為開發前期的工作,還應該包括:總體設計和詳細設計。
總體設計這個階段必須回答的關鍵問題:概括地說,應該如何解決這個問題?
首先,應該考慮幾種可能的解決方案。例如,目標系統的一些主要功能是用計算機自動完成還是用人工完成;如果使用計算機,那么是使用批處理方式還是人機交互方式;信息存儲使用傳統的文件系統還是數據庫……
通常至少應該考慮下述幾類可能的方案:
低成本的解決方案
系統只能完成最必要的工作,不能多做一點額外的工作。
中等成本的解決方案
這樣的系統不僅能夠很好地完成預定的任務,使用起來很方便,而且可能還具有用戶沒有具體指定的某些 功能和特點。雖然用戶沒有提出這些具體要求,但是系統分析員根據自己的知識和經驗斷定,這些附加的能力 在實踐中將證明是很有價值的。
高成本的"十全十美"的系統
這樣的系統具有用戶可能希望有的所有功能和特點。系統分析員應該使用系統流程圖或其他工具描述每種 可能的系統,估計每種方案的成本和效益,還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統 ?。ㄗ罴逊桨福?,并且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統,則可以著手完成本階段的另一項主要工作。
上面的工作確定了解決問題的策略以及目標系統需要哪些程序,但是怎樣設計這些程序呢?
結構設計的一條基本原理就是程序應該模塊化,也就是一個大程序應該由許多規模適中的模塊按合理的層次結構組織而成??傮w設計階段的第二項主要任務就是設計軟件的結構,也就是確定程序由哪些模塊組成以及模塊間的關系。通常用層次圖或結構圖描繪軟件的結構。
詳細設計總體設計階段以比較抽象概括的方式提出了解決問題的辦法。詳細設計階段的任務就是把解法具體化,也就是回答下面這個關鍵問題:"應該怎樣具體地實現這個系統呢?"這個階段的任務還不是編寫程序,而是設計出程序的詳細規格說明。這種規格說明的作用很類似于其他工程領域中工程師經常使用的工程藍圖,它們應該包含必要的細節,程序員可以根據它們寫出實際的程序代碼。通常用 HIPO 圖(層次圖加輸入/處理/輸出圖)或PDL語言(過程設計語言)描述詳細設計的結果。
我想這樣的文檔系統的思路是一個慢慢積累的過程,如JJX同志所說,我們現在有太多的形式上的東東,它并不是一個程序員真正需要的系統分析/設計書,對于系統的設計到實施到最后的代碼以及驗收有太多的改動和變化,我們正在一個極不規范的系統中生存,所以我們不可能有太多的選擇,只能抄抄應付了事。所以與大家一起探討一個真正適合我們的文檔模式,這個模式或是說模板能為我們的代碼工作減少負擔,帶來更多的動能,就目前的開發思路,應用環境和編程方法來說,傳統的需求分析-系統分析-概要設計-詳細設計-……已越來越不行了,因為:
原文轉自:http://www.anti-gravitydesign.com