Posted on 2009-11-26 23:59
leekiang 閱讀(302)
評論(0) 編輯 收藏 所屬分類:
架構設計
NetReptile推薦?[2005-2-1]
出處:來自網上
作者:truely,bylsfboy等
?
truely眼中的設計定義:設計的過程就是將事務處理抽象成計算機模型的過程。
1. 首先要明白設計遠比編程重要。
2. 平時注重訓練自己的思維嚴謹性和從全局考慮問題的能力。建立冷靜思考問題的處事態度。
3. 設計時(尤其是數據庫設計時)不要完全被規矩約束,設計好比作詩,懂得韻律是對的,但完全被韻 律所束縛,就作不出好詩了。
4. 多做設計,經常總結自己的不足之處和成功之處,向他人請教。
5. 專門去找別人設計的漏洞和不足,也是提高自己設計水平的重要手段。
(記住:這個好方法不要順便外傳,自己知道就行了,嘻嘻-:)
6. 經驗是重要的,但如果觀念老化而不善于總結提高,所謂的經驗就成為束縛自己進步的枷鎖。
7. 學好數學特別是理論數學如數學分析、運籌學、數學模型等。多玩策略性經營游戲也是有益的。推薦 《帝國時代》和《模擬首都3000》以及《大富翁4》。(但不要沉陷在里面)
8. 根據項目情況和開發平臺工具的特點確定最佳的設計方法。模塊化設計方法和面向對象設計。兩種設 計方法的結合使用。
9. 將復雜無序的過程用模塊化的方法進行分解,但要注重事務間的聯系,并且用開放的眼光去設計。
10. 設計時對嚴謹性、靈活性、開發效率、客戶要求四個方面做衡量取舍。
11. 設計時還要根據整個工程的進度安排和客戶對軟件的要求而決定是否設計得足夠靈活和嚴謹。
12. 復雜而無條理是最糟的設計,簡單實用并不一定是最好的,但一定不是最壞的。(不要說我偷懶喲)
13. 訓練自己良好的表達能力,能用清晰明確而且簡單的描述表達出自己的基本思路。
14. 在一個項目中建立統一的系統分析模式和文檔模板,同時,一個項目中必須至少有一個人對整個系統 設計進行檢查和進行全局的考慮。
再談如何成為一個好的系統分析員?
bylsfboy
系統分析員基本功:
好的系統分析員都是從優秀的程序員中產生的,堅實的編程功底、豐富的經驗是今后做系統分析的基礎。
沒有對系統本身進行過透徹剖析過,很難領會到其中一些難以言述的精華。但并不等于好的程序員就能夠 成為好的系統分析員。
合
理的知識結構。語言能力、文字表達能力、技術的全面性等是對系統分析員的基本要求。比如說c/s和3
層開發,如果僅僅對netscape公司的產品熟悉還不夠,還需要了解比如微軟等產品,并且要了解他們中產
生歷史,發展思路,技術優劣,以應付各種窮追猛打的提問。但更重要的是,這是你為應用定制技術要求 的前提。
系統分析員思想:
全
局觀念是系統分析員必須具備的觀念。如果系統分析員設計時太注重細節,往往會陷入在某個問題上糾
纏不清的泥潭。(93年,我論文指導老師的一席話影響了我隨后幾年對軟件開發的理解----今后計算機會
越來越快,多寫幾行代碼少寫代碼無關緊要,最重要的是整體;一開始就錯了,某個部份編得再好,也是 沒有用的)
任務難度的預測能力
系
統分析員要具備快速的任務難度預測能力以及具備快速確定開發小組人員構成和任務劃分的能力。(我
將這條歸為思想,而不是能力)昆蟲自然會長出翅膀,而思想卻需要長期的浸潤。要做到這點,需要大量
的思考、學習。設計遠比編程重要。當今軟件業的發展,各種開發工具的出現,編程已經不是什么問題,
程序員的工作某種程度上講是將別人現成的東西拼湊堆砌起來。系統分析員要清楚的認識到,現在大多數
程序員沒有學會怎么去整體的了解一個系統,有些甚至不了解編程(這不是說他們不會寫代碼)。可視化
的開發工具加五花八門的控件,程序員可以偷點懶了。(這可不是夸大,我好幾年的管理工作,接觸過大
量的程序員)基于技術,跳出框架。基于現有技術結合用戶需求思考問題,設計時跳出框架。
系統分析員思想:
系統分析
員要有面向用戶的思想。系統分析員應當有能力將自己扮演成用戶,來了解要交付的項目看起來
想什么樣式,感覺想什么,從而了解用戶的想法并挑選出合理部份去開發。從這個意義上說,系統分析員
才能獲得有意義的見解去引導他的開發組成員。系統分析員頭腦中要對項目結局有一個清楚的認識,并保
證項目不偏離方向。系統分析員要有根植于技術,高于技術思考問題的思想。純粹的程序員通常對最終結
果考慮的不是很多,當一種新的技術在市場上出現時,他們對能否按時交付的考慮就比較少,而強烈希望
他們的計劃能夠建立在新的技術之上。因此,系統分析員的想法和行動要象一個用戶,又要能夠站在技術 的高度,成為真正的用戶、程序員之間的代言人。
系統分析員的關鍵
獲得信任。系統分析員最重要的素質是獲得信任,這是成為優秀系統分析員的關鍵。成熟最為關鍵。成熟 可以為整個項目組提供正確的支持,能夠理解技術怎樣才能解決用戶的需求。
系統分析員的準備工作
統
一的各種文檔模式,這其中包括今后軟件變量、字段命名規則。我推薦用pb制定的規則做基礎,通過改
造成為適合自身實用的標準。統一的文檔管理。統一的分析軟件。比如說rose(uml太規范,國內的軟件
管理水平根本用不上,只不過盡量應用,你自己對系統分析的理解有好處)
方法是思想的放映,在具體方法上就不多說了。我托人從u$a弄到幾本書,用于面向對象系統開發的使
用》、《面向對象的分析》、《項目管理》等都是很不錯的,推薦大家看看。
我在拙作"在中國沒有人懂計算機"里發了點牢騷,聽說挨了部份人(習慣性的)罵。其實,bbs本來就是 發泄的地方,在這里從來就罕有有內容的文章。
自
從"維納斯"登陸深圳后,大家更著眼于從宏觀看中國的it業了。中國it這棵小樹,說實在的,長到今天
實在是不容易。一些人提出了"反對微軟霸權"的口號,不少人呼喚中國"硅谷"的出現。微軟的成功不是技
術的成功,更多的是商業運作的成功。中國it這棵樹能長多高,取決于他所植根于的土壤。而現在的事實是,這片土壤實在是太貧瘠了!如果按我們現在的思路和
搞法,是長不成大樹,更別指望能結出"微 軟","硅谷"這樣豐碩的果實。如果說,我們的軟件技術落后美國十年,我們的硬件制造技術則落后美國
二十年,我們的管理水平落后美國至少三十年。而最終決定發展速率的恰恰是我們的死穴──低劣的管理
水平。低劣的管理水平的形成的原因有著深厚的背景和多方面的原因。
系統分析工作是解決一個問題的工作,目標是將一個對計算機應用系統的需求轉化成實際的物理實現,其中 復雜就復雜在實際的面太多.在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有 幫助.
1)您所完成的系統目的是什么?注意不是功能要求,而是目的.也就是為什么要建設、為什么要現代建設。
2)您所完成的系統有哪些方面參與,各方面的初衷是什么?那些人可能在系統建設中起重要作用,他們 會采取什么樣的態度?你對他們有多少影響力?
3)您的系統是否有一個明確的評價標準?最好從參與的各方面都進行考慮。
4)你的系統設計思想是什么?是否能夠得到各方面的認可。
5)你對參與系統設計開發的人員了解嗎?他們的特長在哪里,是否愿意與你合作,為什么?你對他們有 足夠的影響力嗎?
6)你的系統開發計劃是否完善?你的計劃表有明確的階段嗎?任何一階段都應該怎樣完成?如何對這一 階段完成的情況進行評價?
7)你對所采用的系統開發方法以及工具是否熟悉?你的夥伴是否熟悉?
8)你所完成的系統是否有原型?計算機的或者物理的。
以上的幾個問題都是在系統分析以及系統規劃時涉及到的,供各位參考。
系統分析工作是解決一個問題的工作,目標是將一個對計算機應用系統的需求轉化成實際的物理實現,其中 復雜就復雜在實際的面太多.在系統分析過程之中注意問以下的問題,可能會所進行的系統分析設計工作有幫助
1)您所完成的系統目的是什么?注意不是功能要求,而是目的.也就是為什么要建設、為什么要現代建設。在考慮系統目的時,我更多的側重于系統的最終目標考慮,因為一個系統不可能一下子完美,為系統留些 余地。
2)
您所完成的系統有哪些方面參與,各方面的初衷是什么?那些人可能在系統建設中起重要作用,他們
會采取什么樣的態度?你對他們有多少影響力?中國it行業的失敗之一就是人"太年輕",一定要有領導的
支持,否則完蛋。不要認為自己對他們會有多少影響力,即便有,也要盡可能的認為是決策者再影響他
們。在中國,一個技術員,你算老幾?說到這里我很悲哀。哪些人在系統中起重要作用并弄清楚他們的態 度,這點十分關鍵。
3)您的系統是否有一個明確的評價標準?最好從參與的各方面都進行考慮。不知道這樣說對不對,在系 統建設之前,對你的程序員、對你的領導要有至少不同的兩種評價。
4)你的系統設計思想是什么?是否能夠得到各方面的認可。如果高明,對領導、對程序員都采用引導, 得到認可的最好辦法,就是讓他們認可他們自己的想法。(我力圖這樣做,但做得不好,系統分析員有一 點要學會韜光養晦,忍)
5)你對參與系統設計開發的人員了解嗎?他們的特長在哪里,是否愿意與你合作,為什么?你對他們有 足夠的影響力嗎?軟件發展到一定的程度,不是編程,不是數學,而是管理。
6)你的系統開發計劃是否完善?你的計劃表有明確的階段嗎?任何一階段都應該怎樣完成?如何對這一 階段完成的情況進行評價?
7)
你對所采用的系統開發方法以及工具是否熟悉?你的夥伴是否熟悉?事實上,不是每種好的工具都要
使用,也并不一定都要他們熟練掌握。提醒諸位一句,當你將方案做得可以不依賴某個程序員,你在程序
員面前就無信任可言,因為從此程序員將受到更大的生存壓力。我堅決不在公司使用rose。
8)你所完成的系統是否有原型?計算機的或者物理的。
以上的幾個問題都是在系統分析以及系統規劃時涉及到的,供各位參考。
這文章很好,我的話是:"需求分析實際應該是問題分析"。含義是系統要解決的是問題。而不是用戶提出 的需求。經常發現系統完成后,客戶說"我的問題還沒有解決"。可是,需求分析稿上的目標都搞定了。
既然是問題分析,所以,熟悉目標系統的知識就是必要的。甚至,可以說,一個好的系統分析員也應該是 好的業務專家。
我
很高興在這里遇到許多分析高手,可以交流分析中的問題。我贊同從來的觀點。在中國作分析重要的是
人氣,因為中國的企業級信息系統的建設在很大程度上可以說并非確有需求,而是迫于某種壓力。用戶在
很多時候考慮的不是系統的長遠發展,而只是短期的成果,要求開發單位在很短的時間內完成一個很大的
系統的開發,沒有時間對系統進行周密的分析,在這種情況下,很多開發商就會粗分析,粗設計,盡快進
入編碼階段,這樣的系統的生命周期肯定不會很長。說了這么多,只是想說,系統分析員確實應是業務和
管理專家,并且需要有很好的語言組織能力,他需要根據問題域中存在的問題去盡力說服用戶,引導用戶
需求,畢竟,我們是專家,如果讓用戶牽著鼻子走,系統不會是成功的系統。(當然了,這要建立在用戶 是可引導的前提下)本人拙見。
在理解和分析用戶的需求時,應說服用戶明白:建立計算機應用系統并不是簡單地用計算機代替手工勞
作,它更應該是管理思想的一次革命,是現用戶模式的一次升華和提高。如果系統不能高于現實,開發的系統將長期陷入需求的反復修改,其軟件的生命周期也短了。
針對我對您的問題的理解,試著作如下一般性/理論性的回復:
需求分析(您可以采用usecasedriven的方法進行需求分析)在明確需求分析的基礎上,確定需要采用的系統分析方法(結構化/面向對象/構件式)應用您的開發團隊所確定采用的分析/設計方法,進行系統分析.根據您所采用的分析方法,依次或反復進行系統設計/建模.
http://www.sawin.cn/doc/SA/SATech/NetReptile14.htm