網站項目系統分析及軟件建模 |
作者:九點 |
如果眼光僅僅放在滿足客戶眼下的需求,當問題不斷出現時再不斷修補,頭痛醫頭,腳痛醫腳,甚至系統構架需要不斷調整或重新設計,那么,很快就會陷入代碼泥潭或墜入系統重復開發的無底深淵,當初項目完成時的成就感將被無止境的沮喪所代替。系統分析決定系統開發的成敗,軟件建模使系統開發走向成熟。
本章包括以下內容: 一:系統分析在網站項目管理中的地位 二:系統分析所要做的工作 三:系統分析的難點和技能要求: 四:軟件建模使系統開發邁向成熟 五:總結 一:系統分析在網站項目管理中的地位 在進行了需求分析和業務流程分析并得到客戶的認可之后,對項目進行系統分析是極其重要的。系統分析是能體現整個系統的靈魂的文檔,將客戶的需求從具體到抽象的一個過程,并制定編碼人員可實施的規范和標準。 由于Web應用技術發展的歷史相對與軟件的歷史短得多,在開發網絡應用系統尤其是網站制作的系統設計中設計人員往往對系統分析重視的不夠,特別是設計一些初期比較簡單的或交互及功能較少的網站時,主要原因通常為: 客戶初期的需求比較簡單,忽略了客戶潛在的巨大需求; 項目實施周期短,初期階段采用最快的而不是最合理的實現手段; 經費有限,難以支付高質量的人力費用; Web編程技術手段多樣,容易上手,設計人員參差不齊; 從現實中來看,網站項目的開發與管理和實施遠不如軟件工程規范,在編程語言、數據庫、通信協議、應用服務器等相關環境都在不斷快速發展和完善的情況下,的確很難期望每一個設計師都能網站項目進行系統的合理的分析,從而制定一套跨平臺、健壯的、易擴展和升級的系統方案。 但是,這并不能成為系統分析員逃避或懈怠的借口,如果把一個系統比做一部汽車,系統分析的工作相當于設計發動機,也許很容易就想像的出用125clearcase/" target="_blank" >cc的摩托車發動機去牽引10噸重載卡車會是一個什么樣的后果。 在系統分析的過程中需要對需求分析進行進一步的深化和分析,通??蛻艏皹I務人員在需求分析和流程分析的過程中比較注重功能上的表現和定義,即使是做出正規的用戶界面原型,對系統的需求也是不完整的,處于非技術人員的緣故,很難苛求能提出完整清晰專業的性能需求,但不意味著這需求不存在,而且這隱藏的需求對編碼人員來說是極其重要的。 因此,客戶的需求能否在系統中得到真正的體現和實施,系統分析是至關重要的。 二:系統分析所要做的工作: 把系統分析和詳細設計階段分開,針對不同項目的具體情況再決定采用什么方式進行開發。 那么在系統分析過程中重點要做的是: 對客戶的需求分析進一步完善和補充,尤其是性能需求:讓客戶更加清楚這是一個什么樣的系統,所要達到的功能和性能指標是什么,系統的擴展性和適應性如何,如何為客戶今后的升級或維護提供最有效的方法。 系統運行所需要的的環境:系統能正常運行所需要的硬件、軟件、網絡環境; 系統的資源說明:系統所需要的各種成本。包括人員、時間、工作環境、一次性投入資金、持續性投入資金等所有資源。 系統可行性分析; 對于系統分析員比較苦惱的是大多客戶在系統的要求上提不出獨立的或成熟的意見,而將燙山芋交給了系統分析員的手上,為了避免在系統論證方面難以把握的失控和無從下手,設計幾種不同類型的方案供客戶選擇不失為一個好的方法: “比如通常至少應該考慮下述幾類可能的方案: 1:低成本的解決方案 系統只能完成最必要的工作,不能多做一點額外的工作。 2:中等成本的解決方案 這樣的系統不僅能夠很好地完成預定的任務,使用起來很方便,而且可能還具有用戶沒有具體指定的某些功能和特點。雖然用戶沒有提出這些具體要求,但是系統分析員根據自己的知識和經驗斷定,這些附加的能力在實踐中將證明是很有價值的。 3:高成本的"十全十美"的系統 這樣的系統具有用戶可能希望有的所有功能和特點。系統分析員應該使用系統流程圖或其他工具描述每種可能的系統,估計每種方案的成本和效益,還應該在充分權衡各種方案的利弊的基礎上,推薦一個較好的系統(最佳方案),并且制定實現所推薦的系統的詳細計劃。如果用戶接受分析員推薦的系統,則可以著手完成本階段的另一項主要工作。”(引用《如何寫系統分析書》一文) 經過系統分析的階段,我們就比較容易和客戶在系統如何部署、采用的數據庫類型、設計模型和分析模型等方面達成一致的認識,如果能順利地將客戶的需求業務邏輯分析轉化為程序邏輯,把原先用戶可視化的界面原型和業務流程圖映射成編碼人員理解的模型和規范時,那么恭喜你,項目已經成功了一半。 三:系統分析的難點和技能要求: 網絡應用的開發技術在日新月異地進步,從而使網站應用系統的開發模式具有多種選擇性,達到同樣的目標可以采用很多不同的方式,現代的應用系統越來越成為一個龐大的集成方案,需要考慮不同的操作平臺、不同的應用服務器、不同的數據庫、不同的編程語言、不同的傳輸介質等等,無疑對系統分析員來說是個嚴峻的考驗,任何人都不可能精通甚至說掌握全部的技術,簡單例子:現在有Windows,Unix,Linux等各種服務器操作平臺,有SQL Server,Oracle,DB2,Sybase,MySQL等數據庫,有JAVA,PHP,ASP,CGI,JSP,C++,VB,Delphi等等工具,誰能全部精通呢?如果不能,那么如何確定是Windows+SQL Server+ASP好還是Unix+Oracle+JAVA合適?況且各種軟件和語言還在不斷發展進步之中,超越窄帶的互聯網,今后還可以涉及到寬帶所帶來的變動,或者增加與無線移動的接口,因此系統分析員能否出色的勝任工作很大程度上決定了系統開發的成敗。 系統分析的主要難點在于: 對客戶隱藏的性能需求的分析:由于客戶對尚未實施的系統無法預見,對今后的業務發展也無法預知,對性能需求的分析和定義更需要系統分析員協助客戶去確定和挖掘; 確定項目設計方法:根據項目需求和資源的配置選擇最合適的設計方式。 對系統模塊的劃分和代碼復用的設計:模塊最大化,代碼復用度最高,是一個成熟的系統不斷致力追求的,將大型復雜的應用系統分解成相對獨立,具有高度復用的模塊,各個模塊之間采用規范的參數接口,將大大提高系統的開發效率和維護升級的方便性。即使在網站的模版設計或交互設計上,也盡可能采用嵌套可復用的模版或調用統一的樣式表、JS文件等。 項目整體評估:系統分析員絕不應成為孤立的完美主義者,而需要根據項目的大局出發,比如公司的資源配置、人力狀況、客戶要求等因素評估項目整體和各個模塊的工作量、進度和分配資源,制定出最合理的可行的實施方案。 系統分析員不但需要具備良好的溝通協調能力,更需要具備業務和技術領域兩方面的專業技能,在項目小組中是非常關鍵的角色之一。 四:軟件建模使系統開發邁向成熟 Web應用系統往往隨著客戶的需求增長,開發不斷深入,最終變得非常復雜,而且以Web為核心的網站系統通常都具有高度的動態擴展和交互,要在不完整和不斷改變的需求情況下,在有限的時間內完成一套容易修改和維護的健壯的系統,在UML(統一建模語言)出現之前是極其困難的。 大多的Web設計師或程序開發員為了讓客戶盡快看到可運行的應用系統,經過界面設計或簡單的系統分析后直接進入編碼階段,甚至各個模塊分頭開發,服務器段代碼隨意編寫、數據庫任意添加、參數定義沒有規范,整個應用系統處于一種無序混亂的狀態,當我們采用建模及按照軟件工程的方式進行管理的時候,情況馬上就會好的多。 什么是建模? 建模是使你逐層深入解決問題的辦法; 確認應用系統的功能需求并為事務處理原則建模; 對抽象的對象映射需求,辨認和提供設計模版并創建慣用的模版; 分辨和設計對象或劃分三層模型的服務; 對軟件的組成部分映射成對象并設計組件在網絡上如何分布; UML(Unified Modeling Language,統一建模語言)是一種通用的可視化建模語言,用于對軟件進行描述、可視化處理、構造和建立軟件系統的文檔。UML適用于各種軟件開發方法、軟件生命周期的各個階段、各種應用領域以及各種開發工具,同樣,在網站設計或以網站為表現形式的各種網絡應用項目中,UML也表現出強大的作用。UML能夠描述系統的靜態結構和動態行為:靜態結構定義了系統中重要對象的屬性和操作以及這些對象之間的相互關系;動態行為定義了對象的時間特性和對象為完成目標任務而相互進行通信的機制。UML不是一種程序設計語言,但我們可以用代碼生成器將UML模型轉換為多種程序設計語言代碼,或使用反向生成器工具將程序源代碼轉換為UML模型。 我們可以看的出,建模并不等同于程序編碼,利用同樣的UML模型可以生成不同語言的框架代碼,而且可以通過反向生成,在編寫代碼過程中及時更新UML模型,這對系統分析員和項目管理人員來說是夢寐以求的。只要能夠仔細地把握客戶的需求,不斷改進UML模型,那么采用什么樣的語言開發已經成了次要,大量的需求積累和分析工作能在客戶需求變化時得到高度的復用,即使系統采用新的語言重新開發,需要的也僅僅是編碼部分的工作。 雖然軟件建??梢栽陂_發的任何階段進入,但是在設計初期,應該將精力更加集中在系統功能及性能分析、系統運行環境、選擇編程語言等,而不是考慮考慮程序的細節,如在屏幕上的什么位置放置按鈕等。在項目開發的中期引入建模是非常有意義的,通過建模把握程序開發的方向,準確完成需求分析中所要求的任務。 在高展先生的《全程建?!芬晃闹嘘U述的“全程鏡像一體化建模方式“,整個建模過程依靠業務驅動,在模型設計中利用盒子的上下兩部分分別代表業務組織結構和軟件邏輯結構,將客戶可視的具體的需求與系統抽象的邏輯流程一一對應,這對缺乏技術背景的客戶代表和經驗不足的系統分析員之間的溝通具有明顯有效的作用。 五:總結 系統分析是項目開發中最艱巨的工作,本階段需要特別注意的工作重點在于: 補充完善上一階段可能欠缺的系統的性能需求; 系統分析員需要站在全局出發,設計合理可行的設計方案; 在需求不明的情況下設計多種解決方案供客戶選擇, 將系統分解模塊,最大限度地設計代碼復用; 使用UML建模方式,將客戶變化的需求映射到模型中,大大提高系統的擴展性和開發效率 |
原文轉自:http://www.anti-gravitydesign.com