軟體開發的過程

介紹

在軟體工程中，軟體開發方法（也稱為系統開發方法，軟體開發生命周期，軟體開發過程，軟體過程）是将軟體開發工作劃分為包含旨在更好的活動的不同階段（或階段）。規劃和管理。它通常被認為是系統開發生命周期的一個子集。該方法可以包括由項目團隊建立和完成以開發或維護應用程式的特定可傳遞物和工件的預定義。

常用方法包括瀑布式，原型設計，疊代和增量開發，螺旋式開發，快速應用程式開發，極限程式設計和各種類型的靈活方法。有些人認為生命周期“模型”是一類方法論的更通用術語，而軟體開發“過程”則是一個更具體的術語，指的是特定組織選擇的特定過程。例如，有許多特定的軟體開發過程适合螺旋生命周期模型。

420px-Three_software_development_patterns_mashed_together.svg.png

這三種基本方法适用于軟體開發方法架構。

多年來，各種這樣的架構都在不斷發展，每個架構都有自己公認的優點和缺點。一個軟體開發方法架構不一定适合所有項目使用。根據各種技術，組織，項目和團隊考慮因素，每個可用的方法架構最适合特定類型的項目。

軟體開發組織實施流程方法以簡化開發過程。有時，承包商可能需要采用的方法，例如美國國防工業，需要基于流程模型的評級來獲得合同。描述選擇，實施和監控軟體生命周期的方法的國際标準是ISO / IEC 12207。

長達數十年的目标是找到可重複，可預測的流程，以提高生産力和品質。有些人試圖将看似不守規矩的軟體設計系統化或形式化。其他人将項目管理技術應用于設計軟體。如果沒有有效的項目管理，軟體項目可以很容易地延遲傳遞或超出預算。由于大量軟體項目在功能，成本或傳遞時間表方面無法滿足他們的期望，是以缺乏有效的項目管理。

組織可以建立軟體工程過程組（SEPG），這是過程改進的焦點。由具有不同技能的線路從業者組成，該團隊是組織中參與軟體工程過程改進的每個人的協作努力的中心。

特定開發團隊也可能同意程式設計環境細節，例如使用哪個內建開發環境，以及一個或多個主要程式設計範例，程式設計樣式規則或特定軟體庫或軟體架構的選擇。這些細節通常不是由模型選擇或一般方法決定的。

曆史

軟體開發方法（也稱為SDM）架構直到20世紀60年代才出現。根據Elliott（2004），系統開發生命周期（SDLC）可被視為建築資訊系統最古老的形式化方法架構。SDLC的主要思想是“以非常慎重，有條理和有條理的方式開發資訊系統，要求從概念開始到最終系統傳遞的生命周期的每個階段，嚴格執行并且順序地“在所應用的架構的範圍内。該方法架構在20世紀60年代的主要目标是“在大型企業集團的時代發展大規模的功能性業務系統。

方法，流程和架構包括可由組織在日常工作中直接使用的特定禁止性步驟，以及組織用于生成根據特定項目的需求定制的自定義步驟的靈活架構。組。在某些情況下，“贊助商”或“維護”組織分發描述該過程的官方文檔集。具體例子包括：

20世紀70年代

自1969年以來的結構化程式設計

Cap Gemini SDM，最初來自PANDATA，第一個英文譯本于1974年出版.SDM代表系統開發方法論

20世紀80年代

結構系統分析和設計方法（SSADM）從1980年開始

資訊需求分析/軟系統方法

20世紀90年代

面向對象程式設計（OOP）是在20世紀60年代早期開發的，并在20世紀90年代中期成為一種主導的程式設計方法

快速應用程式開發（RAD），自1991年以來

動态系統開發方法（DSDM），自1994年以來

Scrum，自1995年以來

團隊軟體過程，自1998年以來

Rational Unified Process（RUP），自1998年以來由IBM維護

極限程式設計，自1999年以來

2000年

Agile Unified Process（AUP）自2005年起由Scott Ambler維護

途徑

自資訊技術的起源以來，已經使用了幾種軟體開發方法，分為兩大類。通常，管理層或開發團隊選擇方法或方法的組合。

具有不同階段的“傳統”方法（例如瀑布）有時被稱為軟體開發生命周期（SDLC）方法，盡管該術語也可以更普遍地用于指代任何方法。具有不同階段的“生命周期”方法與定義疊代過程的靈活方法形成對比，但是不同部分的設計，構造和部署可以同時發生。

瀑布開發

220px-Waterfall_model.svg.png

瀑布模型中表示的軟體開發過程的活動。還有其他幾種模型來表示此過程。

瀑布模型是一種順序開發方法，其中開發被視為通過幾個階段穩步向下流動（如瀑布），通常：

需求分析導緻軟體需求規範

軟體設計

履行

測試

內建，如果有多個子系統

部署（或安裝）

保養

該方法的第一個正式描述通常被引用為Winston W. Royce在1970年發表的一篇文章，盡管Royce在本文中沒有使用術語“瀑布”。基本原則是：

項目分為連續階段，階段之間可以接受一些重疊和回彈。

重點是一次性規劃，時間表，目标日期，預算和整個系統的實施。

通過廣泛的書面文檔，正式稽核以及使用者的準許/簽收以及在開始下一階段之前的大多數階段結束時發生的資訊技術管理，可以在項目的整個生命周期内保持嚴格的控制。

瀑布模型是一種應用于軟體工程的傳統工程方法。嚴格的瀑布式方法一旦完成，就不鼓勵重新審視和修改任何先前階段。純瀑布模型中的這種“缺乏靈活性”一直是其他更“靈活”模型的支援者的批評來源。它被廣泛歸咎于幾個大規模的政府項目超過預算，随着時間的推移，有時由于大設計前端方法而無法滿足要求。除了合同要求之外，瀑布模型已經在很大程度上被專為軟體開發開發的更靈活和通用的方法所取代。見瀑布模型的批評。

瀑布模型通常也會在每個星期一的黑暗中演奏助記“A Dance in the Dark”，分别代表分析，設計，實施，測試，文檔和執行以及維護。

原型

軟體原型設計是軟體開發過程中活動的開發方法，原型的建立，即正在開發的軟體程式的不完整版本。

基本原則是：

不是一個獨立的，完整的開發方法，而是一種處理更大，更傳統的開發方法（即增量，螺旋或快速應用程式開發（RAD））的標明部分的方法。

嘗試通過将項目分成更小的部分來減少固有的項目風險，并在開發過程中提供更多的易于更改的能力。

使用者參與整個開發過程，這增加了使用者接受最終實作的可能性。

在疊代修改過程之後開發系統的小規模模型，直到原型發展以滿足使用者的要求。

雖然大多數原型是在期望它們被丢棄的情況下開發的，但在某些情況下可能會從原型系統發展到工作系統。

必須對基本業務問題有基本的了解，以避免解決錯誤的問題。

增量發展

可以采用各種方法來組合線性和疊代系統開發方法，每個方法的主要目的是通過将項目分成更小的部分來減少項目的固有風險，并在開發過程中提供更多的易于改變。

執行一系列迷你瀑布，其中瀑布的所有階段都在系統的一小部分完成，然後繼續下一個增量，或者

在進行系統的單個增量的演化，迷你瀑布開發之前定義總體要求，或者

最初的軟體概念，需求分析以及體系結構和系統核心的設計都是通過瀑布定義的，然後是疊代原型，最終安裝最終原型，一個工作系統。

疊代和增量開發

疊代開發 規定建構軟體項目最初較小但卻越來越大的部分，以幫助所有相關人員在問題或錯誤假設可能導緻災難之前盡早發現重要問題。

螺旋發展

400px-Spiral_model_Boehm_1988.svg.png

螺旋模型（Boehm，1988）

1988年，Barry Boehm釋出了正式的軟體系統開發“螺旋模型”，它結合了瀑布模型的一些關鍵方面和快速原型方法，以結合自上而下和自下而上概念的優勢。它強調了許多人認為被其他方法忽視的關鍵領域：有意識的疊代風險分析，特别适用于大規模複雜系統。

重點是風險評估和通過将項目分成較小的部分來最小化項目風險，并在開發過程中提供更多的易變性，以及提供評估風險和在整個生命周期中考慮項目延續的機會。

“每個周期都涉及通過相同的步驟順序，對于産品的每個部分以及每個層次的細化，從整體操作概念文檔到每個單獨程式的編碼。”

圍繞螺旋的每次行程都周遊四個基本象限：（1）确定疊代的目标，備選方案和限制; （2）評估替代方案; 識别并解決風險; （3）從疊代中開發和驗證可傳遞成果; （4）計劃下一次疊代。

開始每個周期，确定利益相關者及其“勝利條件”，并通過審查和承諾結束每個周期。

快速應用開發

220px-RADModel.JPG

快速應用程式開發（RAD）模型

快速應用程式開發（RAD）是一種軟體開發方法，它有利于疊代開發和原型的快速建構，而不是大量的前期規劃。使用RAD開發的軟體的“規劃”與編寫軟體本身是交錯的。缺乏廣泛的預先規劃通常可以更快地編寫軟體，并且更容易更改需求。

快速開發過程始于使用結構化技術開發初步資料模型和業務流程模型。在下一階段，使用原型設計驗證需求，最終完善資料和流程模型。這些階段反複重複; 進一步發展導緻“用于建構新系統的綜合業務要求和技術設計聲明”。

該術語最初用于描述James Martin在1991年引入的軟體開發過程。根據Whitten（2003）的說法，它将各種結構化技術（尤其是資料驅動的資訊工程）與原型技術相結合，以加速軟體系統的開發。

快速應用程式開發的基本原則是：

主要目标是以相對較低的投資成本快速開發和傳遞高品質系統。

旨在快速生成高品質系統，主要通過疊代原型設計（在任何開發階段），積極的使用者參與和計算機化的開發工具。這些工具可能包括圖形使用者界面（GUI）建構器，計算機輔助軟體工程（CASE）工具，資料庫管理系統（DBMS），第四代程式設計語言，代碼生成器和面向對象技術。

重點是滿足業務需求，而技術或工程卓越則不太重要。

項目控制涉及優先開發和定義傳遞期限或“時間框”。如果項目開始下滑，重點是減少适應時間框的要求，而不是增加截止日期。

通常包括聯合應用程式設計（JAD），使用者通過在結構化研讨會中建立共識或以電子方式促進互動，積極參與系統設計。

積極的使用者參與勢在必行。

疊代生産生産軟體，而不是一次性原型。

生成必要的文檔，以促進未來的開發和維護。

标準系統分析和設計方法可以适用于該架構。

靈活開發

“靈活軟體開發”是指一組基于疊代開發的軟體開發方法，其中需求和解決方案通過自組織跨職能團隊之間的協作發展。該術語是在2001年制定靈活宣言時創造的。

靈活軟體開發使用疊代開發作為基礎，但提倡比傳統方法更輕松，更以人為中心的觀點。靈活流程從根本上結合了疊代和持續回報，它提供了連續改進和傳遞軟體系統。

有許多靈活方法，包括：

動态系統開發方法（DSDM）

看闆

争球

代碼和修複

由于對軟體開發人員的日程壓力，“代碼和修複”開發并不是一個深思熟慮的政策。 在沒有太多設計的情況下，程式員立即開始生成代碼。在某些時候，測試開始（通常在開發周期的後期），然後在産品發貨之前修複不可避免的bug。沒有計劃外設計的程式設計也稱為牛仔編碼。

輕量級方法

輕量級方法具有少量規則。其中一些方法也被認為是“靈活的”。

Jim Highsmith的自适應軟體開發，在其1999年的自适應軟體開發一書中有所描述

Alistair Cockburn的Crystal Clear系列方法，

極限程式設計（XP），由Kent Beck和Martin Fowler等人推動。在極端程式設計中，與較舊的“批量”過程相比，階段以極小（或“連續”）步驟執行。（故意不完整）首次通過這些步驟可能需要一天或一周，而不是瀑布模型中每個完整步驟的月份或年份。首先，編寫自動化測試，為開發提供具體目标。接下來是編碼（由成對工作的程式員，稱為“結對程式設計”的技術），當所有測試都通過時完成，程式員無法想到任何需要的測試。設計和體系結構來自重構，并在編碼之後出現。進行編碼的人也做設計。（隻有最後一個功能 - 合并設計和代碼 - 很常見所有其他靈活過程。）為使用者（某些子集）使用者（至少其中一個使用者在開發團隊中）部署或示範了不完整但功能強大的系統。此時，從業者再次開始為系統的下一個最重要的部分編寫測試。

由Jeff De Luca和Peter Coad開發的功能驅動開發（FDD）（1999）

基于ICONIX-UML的對象模組化，使用案例，是Rational Unified Process的輕量級前身

其他

其他進階軟體項目方法包括：

混沌模型 - 主要規則始終首先解決最重要的問題。

增量供資方法 - 一種疊代方法

結構化系統分析和設計方法 - 瀑布的特定版本

慢速程式設計作為較大的慢速運動的一部分，強調在沒有（或極少）時間壓力的情況下進行細緻而漸進的工作。緩慢的程式設計旨在避免錯誤和過快的釋出計劃。

V-Model（軟體開發） - 瀑布模型的擴充

Unified Process（UP）是一種基于統一模組化語言（UML）的疊代軟體開發方法架構。UP将軟體開發分為四個階段，每個階段包括在開發階段的一個或多個軟體的可執行疊代：開始，詳細說明，建構和指南。存在許多工具和産品以促進UP實施。UP的一個比較流行的版本是統一流程（RUP）。

處理元模型

一些“過程模型”是用于評估，比較和改進組織采用的特定過程的抽象描述。

ISO / IEC 12207是描述選擇，實施和監控軟體生命周期的方法的國際标準。

能力成熟度模型內建（CMMI）是領先的模型之一，并基于最佳實踐。獨立評估會對組織如何遵循其定義的流程進行評級，而不是根據這些流程的品質或所生成的軟體進行評估。CMMI取代了CMM。

ISO 9000描述了正式組織的制造産品的過程的标準以及管理和監控進度的方法。雖然該标準最初是為制造業建立的，但ISO 9000标準也已應用于軟體開發。與CMMI一樣，ISO 9000認證并不能保證最終結果的品質，隻能遵循正式的業務流程。

ISO / IEC 15504 資訊技術 - 過程評估也稱為軟體過程改進能力确定（SPICE），是一種“評估軟體過程的架構”。該标準旨在為過程比較設定一個清晰的模型。SPICE與CMMI非常相似。它模拟了管理，控制，指導和監控軟體開發的流程。然後，該模型用于衡量開發組織或項目團隊在軟體開發過程中實際執行的操作。分析此資訊以識别弱點并推動改進。它還确定了可以繼續或整合到該組織或團隊的通用實踐中的優勢。

軟系統方法 - 改進管理過程的一般方法

方法工程 - 改進資訊系統過程的一般方法

正式方法

形式方法是在需求，規範和設計級别解決軟體（和硬體）問題的數學方法。正式方法最有可能應用于安全關鍵或安全關鍵型軟體和系統，例如航空電子軟體。軟體安全保障标準，如DO-178B，DO-178C和通用标準，要求在最進階别的分類中采用正式方法。

對于順序軟體，形式方法的示例包括B方法，自動定理證明中使用的規範語言，RAISE和Z表示法。

随着對象限制語言（以及Java模組化語言等專業化）的應用，特别是模型驅動的體系結構允許執行設計（如果不是規範），軟體開發的形式化也在不斷湧現。

對于并發軟體和系統，Petri網，程序代數和有限狀态機（基于自動機理論 - 參見虛拟有限狀态機或事件驅動的有限狀态機）允許可執行軟體規範，可用于建構和驗證應用行為。

軟體開發的另一個新興趨勢是以某種形式的邏輯編寫規範 - 通常是一階邏輯（FOL）的變體 - 然後直接執行邏輯，就像它是一個程式一樣。基于描述邏輯（DL）的OWL語言就是一個例子。還有一些工作可以将某些版本的英語（或其他自然語言）自動映射到邏輯和從邏輯中映射，并直接執行邏輯。例如Attempto Controlled English和Internet Business Logic，它們不尋求控制詞彙或文法。支援雙向英語邏輯映射和直接執行邏輯的系統的一個特征是，它們可以用英語在商業或科學層面解釋它們的結果。

文章來源：

http://www.kmyunruan.com