軟考架構師(6)——系統開發基礎知識

全文連接:http://www.javashuo.com/article/p-ofmsztfa-gz.htmlhtml

一:軟件生命週期

軟件生存週期,分爲8個階段: 
一、可行性研究與計劃 
二、需求分析 
三、概要設計 
四、詳細設計 
五、實現 
六、集成測試 
七、確認測試 
八、使用和維護 編程

二:軟件開發模型

1:瀑布模型

瀑布模型也稱爲生命週期法,是結構化方法中最經常使用的開發模型。開發如同瀑布,從一個階段流向下一個階段。其思想認爲軟件開發是一個階段化的精確過程,每個步驟都劃分得很明確,階段之間有明顯的界線。安全

當軟件需求明確、穩定時,能夠採用瀑布模型,一旦需求變更劇烈,每每到測試階段才暴露,形成修改代價太大,風險難以控制。網絡

2:演化模型

若干次瀑布模型的迭代。原型的基礎上,根據用戶在調用原型的過程當中提出的反饋意見和建議,對原型進行改進,得到原型的新版本,重複這一過程,直到演化成最終的軟件產品。數據結構


根據迭代內容,演化模型能夠演變爲螺旋模型、增量模型和原型法開發。架構

3:增量模型

增量發佈將系統劃分爲若干版本,每個版本都是完整的。版本的劃分要均勻。框架

4:螺旋模型

特色是強調風險,每次瀑布模型迭代前,引入風險控制。將軟件項目分解成一個個小項目,每一個都標識風險,直到全部風險都被肯定。 
演化模型適合高風險項目。post

5:原型

 

 

部分衍生關係:性能

 

6:快速應用開發(RAD)

  是一個增量型的軟件開發過程模型,強調極短的開發週期。RAD模型是瀑布模型的一個高速變種,經過大量使用可複用構件,採用基於構件的建造方法贏得快速開發。若是需求理解得好且約束了項目的範圍,利用這種模型能夠很快地建立出功能完善的信息系統。其流程從業務建模開始,隨後是數據建模、過程建模、應用生成、測試及反覆。單元測試

RAD只能用於信息系統的開發,不適合技術風險很高的狀況。

7:敏捷開發

極限編程,自適應編程,特性驅動開發,水晶方法,Scrum

增量迭代開發,整個開發過程由若干個短的迭代週期組成,一個短週期稱爲一個sprint,長度2到4周,甚至1周。 
scrum按照優先順序對用戶需求進行排序、開發,每一個條目稱爲用戶故事。

基本原則一致爲:

從開發者角度,主要關注點有短平快會議(Stand Up)、小版本發佈(Frequent Release)、較少的文檔(Minimal Documentation)、合做爲重(Collaborative Focus)、客戶直接參與(Customer Engagement)、自動化測試 (Automated Testing)、 適應性計劃調整 (Adaptive Planning)和結對編程 (Pair Programming);

從管理者的角度,主要的關注點有測試驅動開發(Test-Driven Development)、持續集(Continuous Integration)和重構(Refactoring)。

7:構件組裝模型

面向構件的編程(COP):

關注於如何支持創建面向構件的解決方案。一個基於通常 OOP 風格的 COP 定義以下( Szyperski ,1995):

面向構件的編程須要下列基本的支持:

——多態性(可替代性);

——模塊封裝性(高層次信息的隱藏);

——後期的綁定和裝載(部署獨立性);

——安全性(類型和模塊安全性)。 

 

8:統一過程

二維模型,橫軸是時間,縱軸是工做內容。

RUP 也稱爲 UP 、統一過程,其核心特色是:以架構爲中心,用例驅動,迭代與增量。該開發模型分4個階段,分別爲:

初始:是爲系統創建業務模型並肯定項目的邊界。

細化:肯定系統的體系結構細化階段的任務是分析問題領域,創建健全的架構基礎,淘汰項目中最高風險的元素。

構造:在構建階段,要開發全部剩餘的構件和應用程序功能,把這些構件集成爲產品,並進行詳細測

交付:交付階段的重點是確保軟件對最終用戶是可用的。交付階段的主要任務是進行β測試,製做產品發佈版本;對最終用戶支持文檔定稿;按用戶的需求確認新系統;培訓用戶和維護人員;得到用戶對當前版本的反饋,基於反饋調整產品,如進行調試、性能或可用性的加強等。 

10:軟件重用

 

11:基於架構的軟件設計

1:ABSD

1)ABSD有3個基礎: 
功能分解 
選擇架構風格來實現質量和業務需求 
使用軟件模板

2)ABSD方法與生命週期

3:ABSD開發模型

ABSDM。將這種基於架構的軟件過程劃分爲 
架構需求、設計、文檔化、複審、實現、演化6個子過程。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 三:軟件開發方法

 淨室方法

  淨室方法從使用盒結構表示的分析和設計模型入手,一個「盒」在某特定的抽象層次上封裝系統(或系統的某些方面)。經過逐步求精的過程,盒被精化爲層次,其中每一個盒具備引用透明性:每一個盒規約的信息內容對定義其精華是足夠的,不須要信賴於任何其餘盒的實現。這使得分析人員可以層次地劃分一個系統,從在頂層的本質表示轉移向在底層的實現特定的細節。

淨室方法主要使用三種盒類型:

(1)黑盒。這種盒刻劃系統或系統的某部分的行爲。經過運用由激發獲得反應的一組變遷規則,系統(或部分)對特定的激發(事件)做出反應。

(2)狀態盒。這種盒以相似於對象的方式封裝狀態數據和服務(操做)。在這個規約視圖中,表示出狀態盒的輸入(激發)和輸出(反應)。狀態盒也表示黑盒「激活歷史」,即,封裝在狀態盒中的,必須在蘊含的變遷間保留的數據。

(3)清晰盒。在清晰盒中定義狀態盒所蘊含的變遷功能,簡單地說,清晰盒包含了對狀態盒的過程設計。

結構化方法

  結構化方法屬於自頂向下的開發方法,其基本思想是「自頂向下,逐步求精」,強調開發方法的結構合理性及所開發軟件的結構合理性。結構是指系統內各個組成要素之間的相互聯繫、相互做用的框架。結構化開發方法提出了一組提升軟件結構合理性的準則,如分解與抽象、模塊獨立性、信息隱蔽等。

  針對軟件生存週期各個不一樣的階段,它包括了

結構化分析(Structured Analysis,A)、結構化設計(Structured Design,SD)結構化程序設計(Structured Programing,P)

面向對象方法

面向對象方法是當前的主流開發方法,擁有大量不一樣的方法,主要包括OMT(對象建模技術)方法、Coad/Yourdon方法、OOSE(面向對象的軟件工程)及Booch方法等,

而OMT、OOSE及Booch最後可統一成爲UML(統一建模語言)。

詳情請參考:《軟考架構師(14)——面向對象方法 》

原型法

拋棄型原型:主要用於解決需求不肯定性,二義性,不完整性,和含糊性

演化性原型:爲開發增量式產品提供基礎,主要用於必須易於升級和優化,適合於Web的項目

逆向工程

再工程:

軟件重構:

逆向工程:

實現級:包括程序的抽象語法樹、符號表、過程的設計表示。

結構級:包括反映程序份量之間相互依賴關係的信息,例如調用圖、結構圖、程序和數據結構。

功能級:包括反映程序段功能及程序段之間關係的信息,例如數據和控制流模型。

領域級:包括反映程序份量或程序諸實體與應用領域概念之間對應關係的信息,例如實體關係模型。

 

 四:系統規劃

1:可行性分析

(1)技術可行性。

(2)經濟可行性。

(3)操做可行性。

2:成本效益分析

 

3:新舊系統分析與比較

 

 

五:需求工程

1:需求獲取

用戶訪談,用戶調查,現場觀摩,閱讀歷史文檔,聯合討論會

2:需求分析

業務流程分析:

數據流圖:數據的流動方向

數據字典:數據的信息集合

3:需求定義

 

4:需求管理

 

六:軟件測試

1:類型

動態測試:運行程序時發現錯誤,分爲黑盒【等價類劃分,邊界值分析,錯誤推測,因果圖】,白盒【邏輯覆蓋,循環覆蓋,基本路徑法】,灰盒

靜態測試:指被測試程序不在機器上運行,而採用人工檢測和計算機輔助靜態分析的手段對程序進行檢測,有桌前檢查,代碼審查,代碼走查

2:測試的階段:

1:單元測試:

其目的在於檢查每一個程序單元可否正確實現詳細設計說明中的模塊功能、性能、接口和設計約束等要求,以及發現各模塊內部可能存在的各類錯誤。

單元測試須要從程序的內部結構出發設計測試用例,多個模塊能夠平行地獨立進行單元測試。

2:集成測試:

  它將已經過單元測試的模塊集成在一塊兒,主要測試模塊之間的協做性。從組裝策略而言,能夠分爲一次性組裝和增量式組裝(包括自頂向下、自底向上及混合式)兩種。

模塊並非一個獨立的程序,在考慮測試模塊時,同時要考慮它和外界的聯繫,用一些輔助模塊去模擬與被測模塊相聯繫的其它模塊。這些輔助模塊分爲兩種:

(1)驅動模塊:至關於被測模塊的主程序。它接收測試數據,把這些數據傳送給被測模塊,最後輸出實測結果。

(2)樁模塊:用以代替被測模塊調用的子模塊。樁模塊能夠作少許的數據操做,不須要把子模塊全部功能都帶進來,但不容許什麼事情也不作。

3:確認測試:

確認測試也稱爲有效性測試,主要包括驗證軟件的功能、性能及其餘特性是否與用戶要求(需求)一致。確認測試計劃一般是在需求分析階段完成的。根據用戶的參與程度,一般包括如下4種類型:

(1)內部確認測試:主要由軟件開發組織內部按軟件需求說明書進行測試。
(2)Alpha 測試:由用戶在開發環境下進行測試。
(3)Beta 測試:由用戶在實際使用環境下進行測試。
(4)驗收測試:針對軟件需求說明書,在交付前以用戶爲主進行的測試

4:系統測試:

若是項目不僅包含軟件,還有硬件和網絡等,則要將軟件與外部支持的硬件、外設、支持軟件、數據等其餘系統元素結合在一塊兒,在實際運行環境下,對計算機系統進行一系列集成與確認測試。

通常來講,系統測試的主要內容包括功能測試、健壯性測試、性能測試、用戶界面測試、安全性測試、安裝與反安裝測試等。

系統測試計劃一般在系統分析階段(需求分析階段)完成。

3:性能測試

相關文章
相關標籤/搜索