試論軟體工程的應用

才智咖 人氣:2.85W

需求分析就是體現我們的委託人對軟體應用的要求,客戶對軟體的要求決定了軟體的開發程式,以下是小編蒐集整理的一篇探究軟體工程應用的論文範文,供大家閱讀參考。

試論軟體工程的應用

摘要:在這裡我們主要通過分析軟體開發過程中存在的問題,來進一步分析在這裡流程之中引入軟體工程的概念,並概括了利用軟體工程進行軟體開發中最重要的3個方面。但當時軟體開發基本上還是依賴開發人員的個人技能,沒有可以遵循的原理、原則和方法,同時也缺乏有效的管理;軟體的複雜性和其中包含的錯誤達到了開發人員難以控制的程度。

關鍵詞:軟體工程;需求

一、軟體工程的起源

相當長一段時間我們發現,特別是60年代以來,計算機普及的趨勢越發的明顯,我們傳統產業中的軟體開發所面臨的問題域的複雜性得到了突出的爆發,這就是我們在很大程度上凸顯系統的規模和複雜度空前擴大。與以前的開發模式不同,原來的軟體開發在很大程度上是依賴開發人員的個人技能,在這個流程之中我們很難發現遵循原理、原則和方法,與此同時我們也可以發現其中管理的落後;這就是使我們的軟體開發中的難度很大的難控性。

二、需求分析是軟體開發的關鍵

我們在軟體開發這一工作流程中,工作中對我們最為關鍵的就是需求分析的`工作,所謂的需求分析就是體現我們的委託人對軟體應用的要求,客戶對軟體的要求決定了軟體的開發程式。這就會使我們在很多的流程之下,在這一流程之後我們不難發現的問題就是與實際要求差距還是較為明顯,在最差的情況下甚至失去了其存在的價值。究其根本原因在我我們的基礎工作沒有做好,就是我們所說的需求分析問題。現行的需求分析還存在著很多的弊端,在這裡我們發現一部分開發者在進行需求調查時,需要我們的委託人,或者說我們的客戶提供應用模型和原始資料,在很大程度上絕大部分使用者往往不知道應該提供什麼,這就出現了需求的提出和客戶真正的需求偏離的問題,也就為我們的軟體開發從根本上買下了隱患。這就要求我們建立全新的需求調研流程,適應客戶新的需求。

(一)我們提倡委託人與開發小組面對面交流

(二)軟體開發小組需要組織具體人員,親自到合作單位開展調研,其最適合的調研範圍是每人負責3至4各部門。其調研的主要工作:1.通過調研表哥瞭解調研資訊;2.針對調研資訊開展統計工作,並在此基礎上展開調研的資料分析。

(三)我們需要對於調研資料進行優化分析,並在此基礎上得出我們需要的結論,對資料的使用優中選優,及時提出不符合調研標準的資料內容,需要明確的是:資料的具體部門分析的差異性,需要我們分清楚部門的差異,便於我們統計工作的展開,這類資料也要注意剔除掉。針對於彙總表的製作更為關鍵,檢查報表上所需要的資料是否在資料調查表中有遺漏;需要針對不同的部門予以劃分。

(四)我們的軟體開發需要根據客戶提供的資料、管理的流程予以確認,並在此基礎上形成文字材料,並反饋給相關的部門,予以確認。

(五)反饋之後我們的職能部門需要製作一個DEMO演示程式;這個延時的介面在很大程度上基本的演示了我們需要實現的功能,該程式只是大概反映出功能呼叫、介面等,這是跟需要我們的客戶提供修改意見。

(六)根據使用者意見進行修改並形成交付使用者審閱的需求分析檔案。

三、系統功能確定力求準確

我們的軟體設計需要很好地完成客戶對軟體功能的要求,我們在設計系統功能時,需要明確是否完成需求的實現;我們需要注意的是,我們容易出現的問題是我們的設計人員在滿足委託人需求的同時,對於其它伴隨的需求的漠視。這些功能恰是客戶主題需要得以實現的關鍵部分,客戶卻在他的需求表述中沒能很好的體現,這類要求我們稱為“系統需求”。比如說在使用者提出的要求中,一般情況下我們的資料要求以編碼方式實現儲存時,這樣的客戶需求就是是要求我們要有一個或多個數據關係表(TABLE)存放編碼和編碼所對應的內容資訊,這就是要求我們的技術人員在實施程式設計時確定系統功能時,就應在在我們的工作中要有一套管理功能對這些資料關係表實現維護。我們從另外一個角度來分析一下,我們的技術人員在實現這一功能時需要對使用者一些自己說不清楚的,然而我們的程式設計技術上比較複雜的功能要求持著謹慎的態度。我們具體來說一下,一般情況下MIS系統的需求中都提出“決策庫”的要求,我們的委託人一般意義上會讓我們的技術人員“決策庫”具有動態、自動、

模糊等決策比較功能,提的要求標準非常高,而結合他們自身的管理究竟如何實現這些功能,參與決策的資訊是那些資料,其計算公式如何則一點也說不清楚。在這種情況下一定要慎重,必要時雙方協商決定。概要設計檔案完成後,開發單位的技術總負責人應嚴格審查其中的功能及如何實現這些功能的描述。如果出現不清楚的描述或根本不可能實現的功能,則屬於設計質量不合格。

四、軟體文件規範化

我們的程式設計人員在很多時候在程式設計的不同階段,在每一個過程中我們會產生不同的文件,文件是我們變成流程中的結果。我們在這一流程中實現的文件不是在軟體開發之後,是在這流程式設計的流程之中。這就要求我們的軟甲工作人員需要在流程中實現文件的生成。我們的軟體開發的過程中,各個階段之間的轉移就是要通過文件來實現的。我們這裡著重說一下重大專案的軟體開發,我們的工作人員需要有清晰的文件語言,文件是相互協調的最清晰語言。文件也是軟體測試的根據。不論大的軟體公司還是軟體開發工作室,都要依據自己的工作,制定軟體文件規範,以此來要求開發人員生產出高品質的軟體產品,這是非常必要的。這需要我們的軟體程式設計人員把流程規範化,形成書面的材料也就是我們所說的文件形式。文件必須嚴格地與各階段的工作一致,準確地反映工作實際,文件修改時,還要保持文件本身前後階段的一致。

我們現在的軟體工作人員在很多方面需要在傳統的軟體工程方法採用結構化程式對它進行設計技術,通常意義上講我們的軟體程式開發是一種有效的方法,但將它推廣至大規模的系統開發中往往會失效。相對於傳統的軟體工程方法,物件導向的軟體工程方法帶來了全新的一種風格,具有相當頑強的生命力,並以相當驚人的速度發展壯大,各個領域逐漸地採用這種新的軟體工程方法來取代原有的傳統方法,同時也取得了輝煌的成就。一直以來,人們夢寐以求軟體工廠的實現,軟體工程師希望能到軟體市場購買各種軟體的“積體電路”來“即插即用”,利用它們拼裝新的軟體系統,而不是一行一行地在自己並不內行的領域低水平地重複他人開發的軟體已經實現了的功能。採用基於元件的軟體開發技術,二進位制元件可以被不同的應用程式使用,使軟體元件真正能夠成為“工業零件”,從而能極大地提高軟體生產率。

參考文獻:

[1]鄒宗華,蔣進,唐曉暉,顧茵莉,何雁,李彬.多頻道、多品牌字幕機綜合應用案例分析及病毒隔離創新機制[J].現代電視技術,2010,10

[2]黃琨,王婉秋,方守恩.道路安全審計輔助軟體設計分析[J].上海公路,2010,03

[3]秦永菊,張東旭.提高中小企業資訊化效率的途徑分析[J].生產力研究,2010,10

[4]張欣.我的地盤我做主[J].中國計算機使用者,2006,33