Atitit各種SDM 軟體開發過程SDP sdm的ddd tdd bdd設計

Atitit各種SDM 軟體開發過程SDP sdm的ddd tdd bdd設計

​​1.1. software development methodology (also known as SDM 1​​

​​1.2. 曆史1​​

​​1.3. 常見方法2​​

​​1.4.  DDD Domain Drive Design，也就是領域驅動開發。2​​

​​1.5. Tdd TDD（測試驅動開發(Test-Driven Development)3​​

​​1.6. TFD -- Test First Development)3​​

​​1.7. BDD BDD指的是Behavior Drive Development，也就是行為驅動開發4​​

​​2. 其他4​​

​​2.1. 驗收測試驅動開發;atdd4​​

​​2.2. CBD（核心Core+行為Behavior+驅動Driver）架構模式4​​

​​2.3. Fdd Feature-driven development4​​

1.1. software development methodology (also known as SDM

 systems development life cycle (SDLC)

1.2. 曆史

1970s

· Structured programming since 1969

1990s

· Object-oriented programming (OOP) developed in the early 1960s, and became a dominant programming approach during the mid-1990s

· Rapid application development (RAD), since 1991

· Dynamic systems development method (DSDM), since 1994

· Scrum, since 1995

· Team software process, since 1998

· Rational Unified Process (RUP), maintained by IBM since 1998

· Extreme programming, since 1999

2000s

· Agile Unified Process (AUP) maintained since 2005 by Scott Ambler

· Disciplined agile delivery (DAD) Supersedes AUP

2010s

· Scaled Agile Framework (SAFe)

· Large-Scale-Scrum (LeSS)

1.3. 常見方法

Methodologies and frameworks

Cleanroom TSP PSP RAD DSDM MSF Scrum Kanban UP XP TDD ATDD BDD FDD DDD MDD

1.4.  DDD Domain Drive Design，也就是領域驅動開發。

DDD指的是Domain Drive Design，也就是領域驅動開發。這是一種非常好的思想，在我們剛開始學習程式，甚至剛開始學習三層架構的時候，我們曾經面臨過很多疑惑，比如如何來實作我們的資料層？後來我們開始學習MVC，MVP等架構，如何設計Model層又成了我們的新問題。我們見過太多這種情況，Model變成了單純的資料容器，也就是我們經常說的貧血模式。DDD實際上也是建立在這個基礎之上，因為它關注的是Service層的設計，着重于業務的實作，是以不可避免的以貧血模式為基礎而存在。但是它最大的特别是将分析和設計結合起來，不再使他們處于分裂的狀态，這對于我們正确完整的實作客戶的需求，以及建立一個具有業務伸縮性的模型，是有很大幫助的。

DDD革命性在于：領域模型準确反映了業務語言，而傳統J2EE或Spring+Hibernate等事務性程式設計模型隻關心資料，這些資料對象除了簡單setter/getter方法外，沒有任何業務方法，被比喻成失血模型，那麼領域模型這種帶有業務方法的充血模型到底好在哪裡？

提倡充血模型，實際就是讓過去被肢解被黑crack的業務模型回歸正常，當然這也會被一些先入為主或被洗過腦的程式員看成反而不正常，這更是極大可悲之處。看到領域模型代碼，就看到業務需求，沒有翻譯沒有轉換，保證軟體真正實作“拷貝不走樣”。

DDD最大的好處是：接觸到需求第一步就是考慮領域模型，而不是将其切割成資料和行為，然後資料用資料庫實作，行為使用服務實作，最後造成需求的首肢分離。DDD讓你首先考慮的是業務語言，而不是資料。重點不同導緻程式設計世界觀不同。

1.5. Tdd TDD（測試驅動開發(Test-Driven Development)

1.6.  TFD -- Test First Development)

1.7. BDD BDD指的是Behavior Drive Development，也就是行為驅動開發 

行為驅動開發是一種靈活軟體開發的技術，它鼓勵軟體項目中的開發者、QA和非技術人員或商業參與者之間的協作。主要是從使用者的需求出發，強調系統行為。BDD最初是由Dan North在2003年命名，它包括驗收測試和客戶測試驅動等的極限程式設計的實踐，作為對測試驅動開發的回應。 

In software engineering, behavior-driven development (BDD) is a software development process that emerged from test-driven development (TDD

行為驅動開發是測試驅動開發的進化，但關注的核心是設

2. 。這裡的B并非指的是Business，實際上BDD可以看作是對TDD的一種補充，當然你也可以把它看作TDD的一個分支。因為在TDD中，我們并不能完全保證根據設計所編寫的測試就是使用者所期望的功能。BDD将這一部分簡單和自然化，用自然語言來描述，讓開發、測試、BA以及客戶都能在這個基礎上達成一緻。因為測試優先的概念并不是每個人都能接受的，可能有人覺得系統太複雜而難以測試，有人認為不存在的東西無法測試。是以，我們在這裡試圖轉換一種觀念，那便是考慮它的行為，也就是說它應該如何運作，然後抽象出能達成共識的規範。如果你用過JBehave之類的BDD架構，你将會更好的了解其中具體的流程。這裡我推薦一

2. 其他

2.1. 驗收測試驅動開發;atdd

2.2. CBD（核心Core+行為Behavior+驅動Driver）架構模式

2.3. Fdd Feature-driven development

FDD是由Jeff De Luca和Peter Code提出來的。FDD在需求和開發步驟上要比XP更加正式，而且還具有精确跟蹤進度的能力。

FDD開發過程主要包括這樣兩個階段：

l         确定待實作的特征集

l         一次實作一組特征

  XP更适用于不穩定的項目，使用者的需求可能是很不明确。XP對這類項目能夠很好的處理，因為它有意的将那些目前不必要的活動推遲到後面的階段

l         與FDD相比，XP适用于小規模的開發。因為XP很大程度上要依賴于項目組的溝通，然而，團隊越大，溝通會越困難

作者:: 綽号:老哇的爪子claw of Eagle 偶像破壞者Iconoclast image-smasher

捕鳥王"Bird Catcher 王中之王King of Kings 虔誠者Pious 宗教信仰捍衛者 Defender Of the Faith. 卡拉卡拉紅鬥篷 Caracalla red cloak

簡稱：： Emir Attilax Akbar 埃米爾 阿提拉克斯 阿克巴

全名：：Emir Attilax Akbar bin Mahmud bin  attila bin Solomon bin adam Al Rapanui 埃米爾 阿提拉克斯 阿克巴 本 馬哈茂德 本 阿提拉 本 所羅門 本亞當  阿爾 拉帕努伊

常用名：艾提拉（艾龍）

頭銜：uke總部o2o負責人，全球網格化項目創始人，

uke宗教與文化融合事務部部長， uke宗教改革委員會副主席

，Uke部落首席大酋長，

uke制度與重大會議委員會委員長，uke保安部首席大隊長,uke制度檢查委員會副會長，

奶牛科技cto ，uke 首席cto  技術總監 研發總監 研發主管 部門總監

uke波利尼西亞區大區連鎖負責人 東加王國區域負責人。

uke克爾格倫群島區連鎖負責人，萊恩群島區連鎖負責人，

uke布維島和南喬治亞和南桑威奇群島大區連鎖負責人

 Uke軟體标準化協會理事長理事長 uke終身教育學校副校長

Uke 資料庫與存儲标準化協會副會長 uke出版社編輯總編

Uke醫院 與醫學院方面的創始人