前言：我們精心挑選了數篇優質計算機行業論文文章，供您閱讀參考。期待這些文章能為您帶來啟發，助您在寫作的道路上更上一層樓。

第1篇

在領悟SWEBOK基本精神，認真學習GSwE2009及《規范》的基礎上，針對一般行業院校碩士生培養目標是以培養從事行業軟件開發及項目管理工作的軟件工程和信息化應用人才為主的現狀，筆者建立計算機科學與技術專業民航特色的高級軟件工程教學大綱，見表1。表1的教學大綱設計兼顧SWEBOK及GSwE2009的核心知識體系，對SWEBOK的核心知識覆蓋率達到76%，對GSwE2009覆蓋率達到63.6%。然而，不管是SWEBOK還是GSwE2009，其核心知識點都是針對整個專業課程體系而設置，SWEBOK的《規范》建議494學時的最小核心學時數，GSwE2009則建議270學時的核心學時及200學時的交流學時，要在36學時內完成上述核心知識的詳細講授，顯然不可能。因此，表1的設計本著宏觀上抓概念、抓流程，微觀上抓工具、抓編程的基本思想，在教學手段上，采用課內外一體化教學模式，要求學生在課下完成所有仿照案例的完整開發過程；在教學方法上，以案例推動軟件過程概念及軟件編碼的學習，以工具熟悉軟件過程管理及軟件質量管理。要求通過該課程的學習，學生能熟練掌握軟件開發過程的宏觀概念，最終交付項目計劃報告、基于MSProject的軟件項目過程管理文檔、經過3次迭代的原形軟件及相關需求分析和軟件設計文檔，完成課程總結報告。

2民航特色的教學案例設計

教學案例設計是高級軟件工程實施的核心內容之一，考慮到選課的大部分研究生已經具備基本的編程能力，但缺少軟件過程管理的相關概念，結合中國民航大學特色及研究生就業趨向，筆者參考國際研究生教育現狀[5]及文獻[6]的模式，開發了一套基于民航航材管理業務的教學案例，用以完成課內教學。該教學案例以某航空公司航材管理系統為背景，采用敏捷開發思想進行過程管理，循序漸進，分3次迭代完成簡單的原型系統開發。第1次迭代在介紹航空公司航材管理需求的基礎上，建立系統的業務環境圖，結合需求分析方法，利用ROSE工具建立業務用例及業務術語表。進一步地，縮小系統范圍，只針對高價周轉件的增刪改查操作建立領域對象模型，包括領域用例模型、用例術語表、領域類模型，同時完成基本的編程實現。第2次迭代首先講述體系結構設計的基本方法，基于MVC框架建立更適合信息系統開發的體系結構框架——PCMEF（表示—控制—中介者—實體—基礎）[6]。在此基礎上進一步細化第1次迭代需求，功能上增加高價周轉件的供貨方管理、合同管理功能；其次建立用例模型和用例文檔，采用序列圖、通信圖、交互圖等描述事務處理流程，進行概念類設計，對第1次迭代的設計按照PCMEF框架完成體系結構重構，完成用戶界面設計，最終編碼實現。第3次迭代增加高價周轉件使用統計報表、機型使用記錄、考慮機務維修周期的周轉件庫存管理等功能，設計上重點考慮數據庫的安全性與完整性設計，同時基于JavaEJB體系結構建立業務組件，完成較高水平的軟件編程；編寫測試用例，完成整體測試。在上述3次迭代完成后，要求學生寫出項目總結。筆者所在學院擁有一個行業特色鮮明的民航信息系統仿真實驗室，該實驗室目前擁有民航機務維修仿真實驗系統、機場信息仿真實驗系統、航空公司運行控制仿真系統、民航全球分銷仿真實驗系統等行業主流信息系統的仿真平臺。學生在前序課程學習中，對這些信息系統的基本功能和相關業務已經有了一定程度的了解。

3教學組織與管理

3.1項目驅動教學法課程教學借鑒CDIO的教學思想，在講授完軟件過程模型及軟件建模語言后，將學生每5人分組，每個人承擔不同的角色，角色包括甲方需求提供人員、乙方項目經理、乙方質量保證人員、乙方編程人員（2人）。在整個學習過程中，經過一定時間后，每個人的角色可以互換。在講授完案例1后，教師可以要求學生結合某個民航信息系統仿真系統，選擇感興趣的民航業務領域，分組完成項目計劃任務書并使用MSProject完成項目的進度安排、人員分工、虛擬費用預算等。進一步地，使用Rose工具進行需求分析及UML建模，完成用例圖、術語表、類圖等分析設計，最后進行第1次迭代的編碼并編寫測試用例完成測試。在講授完案例2后，教師可以要求學生在功能擴展的基礎上，采用PCMEF模式對第1次迭代程序進行重構并完成編碼與測試工作，同時要求項目經理使用MSProject，跟蹤和檢查項目實際進度與虛擬費用預算，進行適當調整。本次學習重點在于體系結構設計、增量模式開發思想。在講授完案例3后，教師可以要求學生繼續擴展功能，重點進行數據庫與業務組件設計。

3.2成績評定在課程進展的每個階段，教師展示實際軟件公司的文檔范例，要求每組提交該次迭代的相關文檔，進行軟件演示并答辯。答辯內容包括項目計劃制訂、人員分工、虛擬成本、進度偏差分析、預算偏差分析、程序設計技術、缺陷分析等。評委由教師及各組項目經理組成。成績評定包含文檔規范性、設計合理性、實現正確性、項目過程管理執行情況4項內容。課程整體結束前，由3次迭代的評定成績取均值作為小組平均成績，最后小組項目經理和教師共同依據小組中個人對項目的貢獻以及小組均值打分，將其作為個人成績。

4結語

第2篇

【摘要】

    本文以某通信公司的業務報表系統開發為例，討論了軟件需求分析工具與方法的選用。我們認為，軟件需求分析是軟件工程中重要的一步，直接關系到后繼工程的進行以及最終的產品能否滿足用戶的需求，因此在整個工程中起著關鍵性的作用。采用適當的工具，有可能顯著減少需求階段的錯誤，也可大幅度提高需求分析的質量和工作效率。當然工具的選用應當與實際的項目相結合，充分地發揮工具的作用。本文結合我們工作的實際經歷，簡要討論了開發系統時所選用的工具及其應用，選用時所考慮的原則以及所碰到的問題。在文中也結合多種開發方法（即傳統的瀑布法、信息工程法、面向對象的方法）的比較，指出各種方法的不足之處，說明我們所采用的工具對軟件需求分析所起的作用，以及相應產生的效果。

【正文】

    我在某市一家通信公司工作，作為一名技術骨于，受領導委托，參與了開發本公司的業務報表系統，我擔任系統的需求分析、總體設計和部分代碼的編寫工作。

    我所在的企業作為一家通信運營公司，分為總部、省級公司和地市級分公司三級，各級公司之間都有數據報表的要求。但是，每一個地市分公司因所處的地方不同，經營環境不同，所面臨的問題也不一樣，因此形成了各具特色的數據報表（除地市分公司向省公司匯報的之外）。公司又分設了許多部門，這些部門也都會需要數據，作為分析決策的依據。因此，了解各個部門的需求就成了業務報表系統的關鍵。

    在調研的過程中，我選用了一種工具叫Play CASE，可以從網上免費下載，有很強的功能。下面就介紹一下，在需求分析階段，我是如何使用這一工具的。

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

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

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

    第四步，將業務上的數據關系轉變成軟件中的數據關系。這里采用了面向對象的方法，把業務部門所需要的數據看作一個實體，部門間的數據關系就是實體之間的關系。比如：經營部門所需要的用戶資料、用戶話費，實際上就是用戶這一實體與賬單這一實體間的關系。Play CASE提供了構件（不過我覺得是部件更為合適一些），來表示對應的數據，并提供了三種構件的表示關系即組裝關系、分類關系與相連關系。這三類關系基本上反映出了現實世界中的業務數據之間的關系。例如現實世界中的用戶資料與用戶話費，在Play CASE中，可將用戶構件與賬單構件用相連關系表示。這種方法，實際上是借鑒了OOA面向對象的分析方法中的類、聚集、繼承、封裝等概念，能較好地反映出現實中的業務；同時，這一步的工作也為總體設計中數據庫的概念模式設計奠定了很好的基礎。

    經歷了上述四個步驟以后，利用Play CASE工具自動生成了軟件需求規格說明書、初步的DFD圖和業務流程圖，為下一步的總體設計打好了基礎。

    使用Play CASE工具，使需求分析既能繼承傳統的結構化分析方法，又能吸收面向對象設計方法的優點。比如能把業務流程轉變成為運行過程，業務組織轉變成了軟件的結構等都體現了這一點。而在運行過程中，對復雜過程的細分以及追蹤則反映了傳統方法中的自上到下分解的分析思想，這對于解決復雜系統的分析是很有幫助的。

    通過使用，我覺得這個工具還是很不錯的。因為它實際將以下四個方面的問題結合起來了：軟件、業務、開發人員和用戶。對于用戶而言，Play CASE用圖形化的方式顯示出業務流程，使用戶了解業務在軟件中的運行過程，提供了將來驗收軟件時的依據。對于開發人員來說，使開發人員能更清楚地了解業務流程，不會再發生“因為不理解用戶的需求而出現的閉門造車情況，從而導致開發出來的產品不符合用戶需要”的現象。因此，Play CASE所自動提供的需求說明書能夠很好地溝通用戶與開發人員之間的理解，使他們都能對需求有共同的理解。

    使用Play CASE工具后，使我們的需求分析取得了很好的效果，不但能自動地提供許多結果，如需求說明書等；還使需求的質量有了很大的提高，受到領導的贊揚（領導不是學計算機的，但對公司的業務十分熟悉）；在后繼的設計與維護工作中，我們感到工作似乎輕松了很多。

第3篇

【摘要】

基于Web技術的數據庫應用是當前應用的一個熱點，在用戶數目與通信負荷很大的場合，提高Web服務器性能是一個迫切的課題。本文從筆者參與某個銀行系統項目開發的經歷出發，闡述了提高Web服務器的性能應滲入到項目論證、選型、開發、運行和管理的各個環節，只有各個環節都能充分考慮到性能與質量的需要，系統的性能才是真正可保證的和可擴充的。

文章從系統的實際運行與相應的經驗出發，闡述了性能改進方面的一些具體措施。

比如：在本文中討論了Web服務器平臺的選型考慮；Web服務器的配置管理；應用系統本身的優化與預先設計系統時可擴性的性能保障等具體內容。

通過技術上的分析與改進，綜合性地運用多類措施與手段，在實際系統中，Web服務器運行的性能得到了一定程度的保證。

【正文】

我所在的單位是把目標定位于金融領域開發IT應用的一家信息技術公司。隨著金融電子化建設的發展和商業銀行之間市場競爭的加劇，各主要商業銀行不斷通過信息技術提供新的金融產品，并且希望能整合市場渠道。比如主要的商業銀行不斷推出形形的網上銀行服務。在這種背景下，本人參與了開發新一代網上銀行產品，涉及到提供網上個人理財服務、網上外匯買賣服務、網上企業服務等具有市場競爭力的產品。作為項目開發的組織者之一和主要的技術骨干，在整個項目開發過程中始終要處于第一線，從而在改進Web服務器性能、提高整個網上平臺系統性能方面收獲良多，在本文中簡要討論如下，希望與讀者們共享經驗。在Web服務器配置與優化方面，我有如下幾方面主要的體會：

第一方面是Web服務器選型考慮。

在Web服務器選型及網上平臺搭建之初，我們就已充分考慮整個網上平臺的性能及可擴展性問題。這一考慮為該系統的穩定性及擴展性能力方面打下了堅實的基礎。

某銀行原有的一些網上產品由于開發較早，故而采用的是老式的HTTP Server+CGI程序調用的方式。這時，每一客戶請求需要對應于后端系統的系統進程來運行CGI程序來處理，系統的開銷相當大，系統的擴展能力也很差，性能已不能滿足業務處理的需要，故而在為此銀行系統具體選型的時候，我們一開始就否決了這種方案。

通過市場上同類產品的比較選擇，我們選擇了國際商業機器有限公司IBM的Web Sphere產品系列作為該行網上銀行系統的建立平臺。作出這樣選擇是因為Web Sphere基于使HTTP Server和應用服務器相分離的整體架構，同時支持JSP、Servlet和企業組Java Bean等輕量級線程規范，所有的請求對應于應用服務器上的處理線程，系統的開銷低、效率非常高，同時Web Sphere整個體系結構相當的靈活，為適應擴展需要可以作不同的橫向和縱向擴展，從而可以滿足各銀行未來的擴展需要。

正是因為在一開始選型的時候我們就已考慮到未來的擴展需要，整個系統在接下來的幾次性能改進方面，我們大體上都能相對順利地達到了預期目標。

第二方面是Web服務器的性能配置。

在一開始系統上線的時候，由于系統的負荷不是很大，為了節省系統總擁有成本TCO投資，我們在一臺較低配置的IBM RS6000上投產了該系統。整個系統的HTTP服務器、應用服務器、通信服務器等均位于該臺機器上，由于初始投產時用戶不多，所以系統的性能基本上能令人接受。

但隨著業務的發展和用戶訪問量的增大，我們發現該服務器的響應變慢，系統的CPU利用率和內外存交換顯著增大。經過跟蹤，我們發現關鍵原因之一是系統的內存不足的緣故。由于網上服務器把大量用戶的會話信息保存在內存中供給應用系統使用，當內存不足時，大量Session信息被迫交換至硬盤，大量CPU時間消耗在等候內外存的交換上，系統效率迅速下降。

鑒于這種情況，我們把該服務器的內存由2GB擴充為4GB，同時相應調整用戶會話信息的保存時間，這樣整個系統的效率又回到較為理想的狀況。

由于新應用的不斷投產及數據庫操作的日益增加，我們后來逐漸監控到系統的數據庫處于繁忙狀態，系統的錯誤日志也記錄下了供應用服務器使用的數據庫連接處出現資源不足的情況。在這種背景下，我們認為整個系統由于硬件配置所限，應該進行橫向擴展，因此我們把數據庫服務器分離出來，配置到另一較高性能的服務器上，相應定義的數據庫資源也大幅增加，這樣整個系統的性能又處于較為理想的狀況。

第三方面是對應用系統進行相應的優化以提高性能。

Web服務器配置及相應的硬件擴展不失為解決系統性能問題的一條捷徑，但應用系統的優化也是應該重點加以考慮的，畢竟它能夠在投入較少的情況下提高系統的運用效率。

在開發的初期，我們就已經十分注意系統的利用效率，比如提醒程序員盡量不要利用用戶會話信息(Session）來傳遞大的對象，對于內存要注意回收等。同時，通過內部的交流會推廣與介紹一些小的、有用的編程技巧來提高開發人員的水平，通過代碼的抽查，希望能在早期就發現問題等。

在系統運行期間，我們通過監控發現，應用服務器所基于的Java虛擬機，其內存堆的空閑空間有不斷下降的趨勢，每隔若干天導致空間消耗殆盡、無法分配新對象空間，從而導致系統重啟。在排除了系統本身問題的原因外，我們確定為應用系統的開發有問題。通過從網上萬載IBM公司檢測Java虛擬機的相關工具對JVM進行監控后終于發現系統內部存在著不能回收內存的對象，再通過查找相應的程序發現在該程序中有“環狀”的對象引用，從而導致對象使用后不能被垃圾收集器所回收。這個問題的解決過程雖然十分艱苦，但由于該問題不能通過升級硬件或增加資源配置而得到根本解決，會給系統帶來很大的隱患。所以，整個過程的分析與解決是完全值得的，更何況通過查找故障原因的過程，給整個項目組上了生動的一堂軟件質量保證課，對項目組的質量意識起了很大的促進作用。

所以說改進Web服務器的性能井不單純是系統管理方面的工作，它滲透到開發以及

系統運行等一系列環節中。

第四方面預先考慮未來的擴展與性能需要。

隨著系統的發展及成熟，考慮到用戶訪問量的不斷上升，為了預留系統的發展空間，我們最近又對整個系統作了一個系統性的升級。通過引入多臺HTTP服務器及應用服務器并行工作提高整個系統吞吐量及單點故障克服能力。由于在一開始選型的時候就已經充分考慮到動態負載均衡及橫向擴展方面的需要，這一項的升級無需對整個系統的體系結構作根本的變革，對應用程序來說，更是沒有造成任何影響。