1. 程式人生 > >第四篇軟件工程總結

第四篇軟件工程總結

危機 可能 都是 過程 進行 源程序 基礎軟件 效率 項目

學習的專業是軟件工程,到了大三學習了軟件工程這門課程,從前幾次的課中讓我印象深刻就是軟件危機吧,對於軟件的開發中發生的失敗沒有任何方法補救,如同書中所說“沒有銀彈”。在《人與神話》中所說“在十年內是不可能有銀彈出現”,經過這麽年也沒有出現銀彈。那軟件開發對於失敗“沒有銀彈”,我們要怎麽避免呢?也許在項目初期進行風險的管理探討,項目遠景和定義和功能集合的詳細定,可以規避掉失敗吧。再到後面的幾節繪制UML圖,UML建模可以幫助我們了解項目流程。以下內容百度,對面向對象系統進行可視化、詳述、構造和文檔化正是統一建模語言(UML)的目的。眾所周知軟件對於一個公司,一個企業乃至一個國家都是十分重要的,因此一個軟件的維護也十分重要,下面我就講一些關於軟件維護的知識。維護階段是軟件生存期中時間最長的一個階段,也是花費的精力和費用最多的一個階段。由於操作系統軟件和基礎軟件版本升級或應用管理系統軟件的不斷開發、完善,需要對軟件進行維護。但當運行環境改變或者系統功能、性能需求發生變化,使原軟件不能通過維護的手段滿足用戶需求時,則需要進行軟件更新。軟件的開發過程對軟件的維護有較大的影響。若不采用軟件工程的方法開發軟件,則軟件只有程序而無文檔,維護工作非常困難,這是一種非結構化的維護。若采用軟件工程的方法開發軟件,則各階段都有相應的文檔,容易進行維護工這是一種結構化的維護。非結構化維護活動只能從閱讀、理解和分析源程序開始,這樣做難以弄清系統功能、軟件結構、數據結構等問題,常常造成誤解。同時由於沒有測試文檔,也不可能進行回歸測試很難保證程序的正確性。這種軟件維護方法僅在軟件工程時代之前采用。在進行結構化維護活動時,需從評價需求說明開始,弄清楚軟件功能、性能上的改變;對設計說明文檔進行評價,並進行修改和復查;根據設計的修改,進行程序的變動;根據測試文檔中的測試用例進行回歸測試;最後,把修改後的軟件再次交付使用。這對於減少精力、減少花費和提高軟件維護效率有很大的作用。

第四篇軟件工程總結