談一下 項目開發中的原型設計- prototype design

在這裡僅僅討論如何去做 prototype , 那些是必須的， 那些是可選的。

此POST 的理由是 我和我們部門經理對於什麼情況下需要做prototype 、 那些是prototype必須的， 那些不是必須，的理解不一樣。
（一） 快速原型方法 的理解
快速原型方法就一種開發方法。在軟體開發過程中，最關鍵的步驟就是確切定義出需求，明確軟體要實現的功能是什麼，而這恰恰也是最困難的過程，因為現在許多使用者在初期只有一個隱約的、大致的考慮，根本不可能提出具體明確的需求。這種情況下，使用快速原型進行反覆交流、細化需求，就成為一種更加有效方法。一個軟體的原型，主要是類比重要的功能和介面，但是一般不考慮運行效率，也不考慮系統的健壯性，出錯處理也考慮不多，它的目的只是為了實際描述概念中的結構，使使用者能夠檢測與其概念的一致性和概念的可用性。（ 一般我們做的系統， 需要介面， 介面元素不是非常簡單的， 都可以使用這個方法）

目前主要有兩種快速原型設計方法：
· 丟棄原型（Throw-away prototyping）。其目標只是為了明確需求，使用最簡單的開發方法，以最低的成本實現一個可工作的系統，該系統只關注功能，不考慮開發工具、效能、容錯、未來實際運行環境等。通過反覆與客戶交流和修改原型，使原型的功能能夠充分體現客戶需求。在明確了需求之後，原型就會被丟棄。以後軟體的開發將根據明確了的需求按照傳統的工程化方法來開發。
· 進化原型（Evolutionary prototyping）。其目標就是與客戶一起工作，從一個原始的需求的輪廓開始，逐步改進，最終發展成為符合實際需要的系統。採用這種方法，就需要考慮到軟體未來的運行環境等有關要求，這就要求從一開始就要對需求有一個比較清晰的認識，不能有方向性的錯誤。

快速原型方法存在的主要問題是：文檔容易被忽略，建立原型過程中的許多工作會被浪費，項目難以計劃和管理。但是這種方法的好處更大：能夠適應不明確的需求，比傳統的瀑布式方法要快得多，使用者的介入更多，能夠及早發現問題從而降低風險。 在軟體開發過程中，面對快速變化的市場需求和新技術發展，最大的風險往往來自對需求的分析和技術實現手段的選擇，通過原型化方法，首先以合理的成本細化需求、實驗技術手段，把最主要的風險降到最低，從而在總體上降低軟體開發的風險，加快軟體產品的形成，降低軟體開發的成本。
( 二) 具體做法
根據客戶已經描述出來的需求， 做出Page static View、Dynmic View ， 使客戶和Team Dev之間有一個共同的具體討論對象。
比如做一個web 應用系統，
原型必須展現出 業務應該有的屬性， 欄位， 相片順序， 使用的控制項的類型， css 表示。
有流程的話，需要表示出流程的流動出來。
不是必要的：
  類比動作的資料問題， 比如submit 一張單據，產生一張新單據等等 。。。
  介面的風格也不是必要的。 ( 這部分可以單獨和客戶談) .

前面也說過， prototype 方式追求的是 快速的開發介面原型和使用者討論需求， 我們追求的是理解上的一致。 我們不必要吧原型做的非常的漂亮和一字不差，那樣的話， 項目的周期和成本都有很大的增加。 
切忌。