1. 程式人生 > >Preliminary Design Review(初步設計評審(回顧))

Preliminary Design Review(初步設計評審(回顧))

架構 int 沒有 com 參加 intern 不同 想要 初步

一、前言

初步設計評審PDR)會話幫助您確保魯棒圖,域模型和用例文本都相互匹配。針對每個用例來說 這個評審是初步設計和詳細設計階段之間的“門戶”橋梁。在本章中,我們提供了PDR的概述,然後我們將展示Internet Bookstore的示例。初步設計評審理論,在本節中,我們將介紹PDR的關鍵要素,包括我們的前10PDR指南。

二、為什麽選擇PDR

為什麽要在魯棒性分析後重新評審你的模型? 這是一個假想的的對話,我們希望能夠對這個話題有所了解:

1、 問:我為每個用例繪制了一個魯棒性圖表,結果我認為用例模型很好。可以開始設計嗎?

答:首先有一個快速

評審步驟:初步設計評審(PDR)。 此評審會話幫助您確保魯棒性圖表,領域模型和用例文本都相互匹配。

2、 問:誰應該參與PDR會議階段

答:和參加需求評審的是同一群人:客戶代表,開發團隊以及密切參與項目的一些管理人員。 客戶將密切參與和涉及這個會議(階段),但這次評審是客戶直接參與的最後階段。 之後,它是詳細的設計 - -這是高級開發人員的工作。

註意:當然,客戶可能仍然對正在進行的工作,截圖等進行評論,但是您不希望非技術性(或更糟糕的是,客觀上)客戶去進行評論或推動未來的設計

3、 問:但是如果客戶想要在以後添加新的需求呢?

:這是一個不同的問題。 我們所說的只是客戶沒有

介入到設計和編碼(即PDR之後的剩余步驟,直到交貨)。

4、 問:如果客戶確實想添加新的要求,這會對流程有什麽影響?

答:對於新的需求那麽至少要回到過程的第1步(根據需要修改用例和域模型)。處理分析和在不斷改變需求的海洋裏進行設計工作是一個復雜的難題,並且在這個過程中伴隨著陷阱(Handling the analysis and design effort in a sea of changing requirements is a complex subject with many pitfalls)。所以我們寫了一個關於這個問題的另一本書。

5、 問:PDR期間還需要實現什麽?

:這是一個很好的機會確保您的實體類已經填充了屬性,在你的系統中的屏幕screen都有名稱,並且可以跟蹤屏幕screen和實體類之間的數據流。

6、 問:如果我們正在做一個詳細的設計,我們還不應該考慮技術架構(TA)?

答:是的,在這個會議(階段)進行的期間,TA也應該被評審 您需要確保新興設計將與您選擇的架構配合使用。

三、十大PDR指南

本章討論的原則(principles)可以概括為一個準則清單。 我們的前10名列表如下:

Preliminary Design Review(初步設計評審(回顧))