返回列表 回復 發帖

電腦系統分析員論文12篇(2)

 步結果的基礎上寫出基本需求,交由客戶評審補充,(3)在第(2)步的基礎上開發原型,利用此原型與客戶交流,從而獲得最終可用的需求結果。下麵按上述三步分別加以論述。

 第一步是實施逆向工程,獲取原有系統的基本需求。
 由於原有系統在功能上大體上能基本滿足客戶的需求,並且在兩年多的開發中也積累了不少經驗,因此,從中可以獲得一些有益的參考,也可以避免多走彎路。在這一階段,我們採用的主要工具是PB自帶的Power Designer和PB Documents;前者主要用來分析資料庫結構,後者主要用來分析程式結構,便於開發人員與高級用戶理解程式。採用這兩個工具的原因是:原系統過於龐大,模組多,資料庫模式多,表格量很大,僅靠人工的方法很難從中獲得一個比較完整的、明確的系統結構以及整體構成,而且原有系統未能提供一套正確完整有效的設計文檔,於是我們只能依靠工具輔助來進行。在使用Power Designer分析資料庫,並且用PB Documents分析原程式中的PBL以後,我們對原系統的結構有了一個初步的瞭解,再結合對原系統的使用,基本明確了功能與流程的需求,並在此基礎上用人工錄入方式,產生了初步需求的自然語言文檔。這裏指出,使用Power Designer的一個不足之處是:如果一個表中的字段過多,而且又同時依賴多個表時,輸出的表格相關圖形很複雜,有很多交叉,且難於調整,不方便閱讀及列印。




 第二步是在第一步的基礎上進行的,即寫出系統基本需求,交由客戶評審和補充。
 通過第一步的逆向工程,我們獲得了系統的基本需求。為了充分記錄需求的變化及需求之間的依賴關係,我們決定選用Rational公司的Requisite PRO作為我們的需求管理工具,Rational公司有一整套用於需求管理的工具,功能非常強大,包括Requisite Pro、Clear Quest等等,這些需求分析工具可以對需求進行全面的管理,包括記錄需求的變化情況,需求之間的依賴關係等等。但是,我們考慮到Rational的一套工具全面實施會非常昂貴與複雜,需要非常強的專案管理能力才能全面實施,因此,我們只採用了其中最簡單的一部分功能,那就是記錄需求變更,記錄需求之間的依賴關係,其他跟RUP有關的功能都給略去了。之所以這樣做,主要是考慮到專案的經費、人力以及國內軟體開發的實際情況。正如前面所說,我們根據自己的理解並寫出基本需求後,交由客戶做評審井做適當補充,我們將經過補充整理後的需求作為正式需求記錄入Requisite Pro所維護的資料庫中,並對各個需求進行分類,設定優先順序等,這些工作完成後,就可以從資料庫中直觀地瞭解客戶到現在為止提出了哪些需求,哪些需求是必須優先考慮的,哪些是難度較大的等等。在這個過程中,我們遇到了一些問題,譬如:用戶對我們用自然語言書寫的需求文檔有許多地方不理解,往往在花了較長時間閱讀之後,仍不明白我們所描寫的需求過程與他們所完成的業務之間的對應關係;另外是由於首次採用Requisite Pro進行需求管理,在類型劃分,屬性值的確定上,部分開發人員沒有經驗,造成了不少反復,對於前者,我們的方法是想辦法增加一些示意圖,將大的流程分解為小流程,再與客戶反復交流與溝通,最終達到雙方理解一致的目的。對第二個問題,則參考了一些例子,再結合實際中屬性的使用情況,給予取捨或者選擇,經過這一階段的工作,我們建立了基本的需求庫,定出了基本需求規格說明。

 第三步則是在第二步的基礎上建立起原型,利用原型與客戶進行更深入的交流,通過交流修改相應的需求。
 在這一階段的工作是在對第二步任務進行報告交流的基礎上進行的。我們用PB開發了一個原型系統,就具體的業務流程與客戶進行交流與溝通,通過原型,客戶發現了許多我們與他們的理解相互不協調的地方,我們在修改需求的同時,也在Requisite Pro需求資料庫中記錄下修改的歷史。事實證明,這種記錄歷史的作用是很有效的,如曾經有客戶在兩個不同的時間對同一需求提了相反的需求,我們根據歷史記錄很快證實了該客戶的提法有錯誤,在事實面前無需再作爭論,同時利用Requisite Pro,我們還發現了一些需求相互之間有矛盾。經過這一階段工作,我們終於獲得了經過用戶認可的需求基線,即是可用於下一步進行詳細設計的基線需求。

 在這個專案中,我們利用了Power Designer、PB Documents等逆向工程分析工具和Requisite Pro需求管理工具,這些工具的使用,使我們提高了工作效率,起到了一定的輔助作用。但是,就需求分析工具方面而言。我們覺得國內應用得還是太少了,這一方面是因為對需求分析不夠重視,另一方面是因為管理水準還達不到相應的層次。Rational公司的一整套需求分析工具,其功能是非常強大的,國外已在普遍地使用,在國內也逐漸開始普及,特別是那些通過CMM二級以上評審的單位,都必須使用工具對需求進行管理。在本項目中,我們僅僅利用了Requisite Pro功能的一些小方面,已經體會到該工具對於專案管理的諸多好處。如果一個有實力的公司能夠全面實施RUP,那麼需求管理這個老大難的問題會變得不再那麼棘手了,專案的品質也會得到相應的提高。目前國內由於CMM熱潮的興起,已經逐漸重視需求分析,也逐漸使用需求分析工具,這是非常可喜的,當然,更希望在不久的將來,能用上國產的需求分析工具,那時我們的軟體產業也許會真正地騰飛了。


 評注;採用逆向工具進行再工程的應用很多,本文給出了一個實際的例子。寫作有條理,也很實際。合理地界定了需求分析的現實水準。所採用的需求分析的方法與工具相對較合理科學。能在對專案討論的同時抒發議論、使用體會、愛國心和事業心。深度還可以提高,例子宜更加豐富一些。(本文主要參考了廣東劉小波等人的論文)


 系統分析員論文3
 論軟體需求分析方法和工具的選用——論文3:通信行業的應用
 【摘要】
 本文以某通信公司的業務報表系統開發為例,討論了軟體需求分析工具與方法的選用。我們認為,軟體需求分析是軟體工程中重要的一步,直接關係到後繼工程的進行以及最終的產品能否滿足用戶的需求,因此在整個工程中起著關鍵性的作用。採用適當的工具,有可能顯著減少需求階段的錯誤,也可大幅度提高需求分析的品質和工作效率。當然工具的選用應當與實際的專案相結合,充分地發揮工具的作用。本文結合我們工作的實際經歷,簡要討論了開發系統時所選用的工具及其應用,選用時所考慮的原則以及所碰到的問題。在文中也結合多種開發方法(即傳統的瀑布法、資訊工程法、面向對象的方法)的比較,指出各種方法的不足之處,說明我們所採用的工具對軟體需求分析所起的作用,以及相應產生的效果。
 【正文】
 我在某市一家通信公司工作,作為一名技術骨於,受領導委託,參與了開發本公司的業務報表系統,我擔任系統的需求分析、總體設計和部分代碼的編寫工作。

 我所在的企業作為一家通信運營公司,分為總部、省級公司和地市級分公司三級,各級公司之間都有數據報表的要求。但是,每一個地市分公司因所處的地方不同,經營環境不同,所面臨的問題也不一樣,因此形成了各具特色的數據報表(除地市分公司向省公司彙報的之外)。公司又分設了許多部門,這些部門也都會需要數據,作為分析決策的依據。因此,瞭解各個部門的需求就成了業務報表系統的關鍵。
在調研的過程中,我選用了一種工具叫Play CASE,可以從網上免費下載,有很強的功能。下麵就介紹一下,在需求分析階段,我是如何使用這一工具的。

 第一步,瞭解業務組織結構。公司內部的數據實際上是在部門之間流動的。業務部門需要知道在本地覆蓋區內各基站的話務量、當天的話務量(即話務量的時空分佈)。財務部門需要知道本月各類用戶的話費收入、預交款收入、與其他電信運營商的網間結算等。計畫部門需要各部門的分析數據。計費部門需要提供本月的賬革統計數據、話單統計數據分佈(比如分別按照基站分佈、時段分佈以及按用戶類別分佈)、預交款統計數據、當前的欠費總額分佈、催繳情況等等。這些部門時常為了數據而產生了大量無謂的爭議。在使用Play CASE工具時,先要將這些部門錄入到Play CASE的“業務部門”中.構成了一個資訊源的接收點(或發送點);而Play CASE通過圖示表示了這些部門的關係,並轉換成了相應的軟體結構。實際上,這是一種系統建模的方法,即把業務系統中的各個組織轉變為軟體功能中的各個結構。這樣,在需求分析階段,明確哪些部門需要數據,從而保證了需求分析對整個公司的全面性,而不會忽略掉某一個部門,導致需求分析的不完整。



 第二步,瞭解各個業務部門中的業務流程,使之通過Play CASE轉換成軟體的運行過程,這是一種動態建模的方法。在上一步的基礎上,追蹤各個部門的行為,錄入到Play CASE中,並以形式化的語言描述各過程。對於複雜的過程,該工具還提供了進一步細化的方法,並且形成了業務流程圖和業務狀態圖。根據這些流程圖、狀態圖與實際業務部門的業務相結合比較,還是較為吻合的。在此步的實施過程中,運用了動態建模技術,使各部門業務流程的情況在軟體的運行過程反映出來,從而保證了需求分析階段中運行過程的描述能真實地反映實際情況,防止在後繼的程式編寫過程中,可能會經常發生的一類情況:程式員因為沒有理解業務流程而出現“閉門造車”的現象,從軟體的功能角度上保證了軟體的正確性。

 第三步,將業務數據轉變為軟體數據,這一步工作實際上就是收集各部門所需要的數據。分析各部門需要的數據都有哪些;以及數據是如何轉換的,這可以歸入“功能建模”的範疇。將這些相應數據錄入到Play CASE中,選定所屬的部門。這時就自動地建立了DFD圖(數據流程圖),數據字典,省去了人工建立時的很大麻煩。

 第四步,將業務上的數據關係轉變成軟體中的數據關係。這裏採用了面向對象的方法,把業務部門所需要的數據看作一個實體,部門間的數據關係就是實體之間的關係。比如:經營部門所需要的用戶資料、用戶話費,實際上就是用戶這一實體與帳單這一實體間的關係。Play CASE提供了構件(不過我覺得是部件更為合適一些),來表示對應的數據,並提供了三種構件的表示關係即組裝關係、分類關係與相連關係。這三類關係基本上反映出了現實世界中的業務數據之間的關係。例如現實世界中的用戶資料與用戶話費,在Play CASE中,可將用戶構件與帳單構件用相連關係表示。這種方法,實際上是借鑒了OOA面向對象的分析方法中的類、聚集、繼承、封裝等概念,能較好地反映出現實中的業務;同時,這一步的工作也為總體設計中資料庫的概念模式設計奠定了很好的基礎。
經歷了上述四個步驟以後,利用Play CASE工具自動生成了軟體需求規格說明
返回列表