A. 一個完整的web項目開發流程
1 需求確定
通過各種方法確定系統的功能與性能。
功能：注冊、登錄、查詢、搜索。。。
性能：可同時支持N個並發訪問，並且響應時間不低於M毫秒。。。
方法：
會議
詢問
頭腦風暴
原型-界面原型、業務原型。。。
本階段是項目開發的最重要的階段。
在WEB項目中，通常界面設計會在本階段進行。
2 分析與設計
1 架構分析與設計
邏輯結構：
3層架構、多層架構。。。
MVC。。。
Model1或Model2
。。。
物理架構：
web伺服器的分布
資料庫伺服器的分布
。。。
技術解決方法的確定：
Java/.net
Open Source/商業
。。。
2 業務邏輯分析
根據需求分析業務邏輯：
有哪些人使用本系統
他們會使用本系統做什麼
通常他們使用本系統的步驟是怎麼樣的
會有哪些明顯的類來支撐本系統的運行
會有哪些不同的提示會反饋給用戶
。。。
本階段與需求的確定密切相關，通常在確定需求的時候就會進行相關的分析。
3 業務邏輯設計
根據需求的分析來確定具體的類
確定類的屬性
確定類的介面（方法）
確定類之間的關系
確定用戶操作流程在設計上的反映
進行資料庫的設計
注意：不同的項目步驟可能不盡相同
4 界面設計
設計系統的界面風格：
顏色、style
設計系統的具體「模擬」界面：
能夠從頭到尾
方便進行需求的確定
方便JSP程序員進行開發
。。。
3 開發環境搭建
開發工具的確定：
eclipse、Myeclipse。。。
配置管理工具的確定
測試工具的確定
文件伺服器/配置伺服器等的確定
。。。
4 開發-測試-開發-測試
按照設計進行開發
迅速開發原型
進行迭代開發
提早進行測試：
單元測試
黑盒測試
白盒測試
性能測試
易用性測試
。。。
5 編寫文檔
B. 如何規劃跟設計web應用程序，其開發周期有那幾個階段
下面用我開發的一個辦公系統來說明一下如何規劃跟設計WEB應用系統，及其開發幾個階段。
第一步：需求分析
我召集他們所有業務相關部門開了幾次會議，將各部門的功能需求進行了整理和統一，寫成的功能需求說明書，文中詳細列出了軟體要解決的實際問題及要達到的目標。他們要求軟體要能解決他們的實際問題，帶來真正的價值。比如直接給他們帶來更多訂單，幫助他們尋找客戶並留住，同時在經營中節省人力成本及防止不必要的浪費，最終實現公司利潤的增長。我認為，如果一個軟體不能帶來實質性的經濟價值，僅僅只是用來裝點公司門面，提高一點工作效率，那還不如不要。這也是他們為什麼看不上有些成品軟體，而要選擇定製開發的原因。每個公司情況均不一樣，成品軟體商往往無法知道每個客戶的痛處，所以做出來的產品無法真正適合客戶。只有自己針對性的開發，才能真正解決問題。客戶才知道他們公司最需要什麼，他們的客戶應如何獲得和留住，業務流程應如何設計等等。有針對性開發一些實用功能，才是最適合的軟體。
通過這個項目，我認識到編寫軟體需求說明書的過程非常重要，這決定了以後的開發過程是不是會走彎路，是否因為開發了不必要的功能浪費時間和金錢，是不是存在程序功能模塊上的沖突。我在需求說明編寫上花了較大精力，有種磨刀不誤砍柴工的感覺。最後在所有人員一致通過這個需求說明書後才決定走下一步。
第二步：開發方案書
開發方案書是將功能需求說明書轉化為可開發的具體行動方案，我根據開發平台的開發規則進行編寫的，將軟體需求說明書中的功能模塊進行組合優化，分析出各個模塊的數據結構及數據關系、運算邏輯，理清各模塊之間的業務流程，最後根據各業務部門人員的實際情況規劃各模塊的界面樣式。
我的開發方案書也寫得很詳細，不過相比功能需求說明書，感覺容易些，畢竟大方向已有了。開發方案書中我將數據結構中的表及欄位全部規劃好，並命名好，包括其數據類型、長度等，做成表格，並將各欄位數據來源及編輯方式等均做好說明。前面忘記說明了，我雖然對編程不懂，但由於以前有過管理軟體操作方面經驗，對資料庫還是有一定了解的，但也只是懂一些皮毛，不過用天縱快速開發平台開發，這點資料庫方面的知識夠用了，以後使用過程中如果需要更復雜的一些SQL語句再網上搜索一下吧。
開發方案書對後期的系統開發非常重要，下面的開發過程其實就是將開發方案書的內容在快速開發平台進行配置的過程。
第三步：開發及測試
有開發方案書，接下來的開發就非常容易了，其實就是將開發方案書的內容配置到開發平台上的過程，這就是我前面說的為什麼找這樣一個開發平台開發這個系統的原因。
用配置型開發平台開發軟體相當簡單快速，一般的模塊三步就可以搞定了，第一步設置模塊信息，第二步設置表單屬性，第三步設置表中每個欄位。也許我這樣說你還是不太相信，那好吧。上圖！
天縱快速開發平台分開發後台和應用前台。顧名思義，開發後台是供開發者使用的，應用前台是開發好的系統進行使用的地方。好了，進入開發後台吧，如下圖：
通過這三步的配置，一個功能模塊基本完成了。是不是非常簡單快速！整體開發過程是不是全部是通過配置來完成的。當然上面提到的是一些最基本的配置，對於復雜功能要求的模塊，可能還要進行更詳細的配置。
配置型開發平台由於省去代碼編寫，開發速度大大提高，由於界面是由開發平台中間件根據配置的業務參數自動生成，不用每個界面均去編寫一套代碼，因此出錯率大大降低，軟體的性能和穩定性自然也就有了保障。
第四步：編寫操作手冊
系統開發好後，有一個收尾工作是不能省的，那就是編寫操作手冊。好在我平時沒事就喜歡寫點博客，對寫作沒有畏懼心。操作手冊是供使用者學習和操作時用的，在操作手冊中我將系統操作過程及其注意事項詳細列出，事後我才知道，操作手冊也是這個系統正式能使用起來的重要因素之一，因為我寫的操作手冊有聲有色，條理清晰，操作這個系統的同事很快就能理解並上手了。
我得出的經驗是：操作手冊越早編寫越好，最好是在開發的同時就進行編寫，開發過程中一些重點內容要立即記錄下來，提醒以後的使用者，時間一長了，就算是開發者本人也可能都忘記了，最後導致使用者走彎路。
第五步：上線試運行
折騰了半個多月，一個共有50多個模塊的內部管理系統基本算是大功告成了，請客戶的幾個部門領導一起演示操作走了一遍，大家十分滿意，總算沒辜負老他們板的期望。他們老闆一高興，批准買一台伺服器專門運行這個系統。我花了一天時間，部署到伺服器上，開始上線試運行。
第六步：正式運行
經過了半個月的試運行，調整了其中出現一些小問題，就開始召集所有部門相關人員進行幾天的操作培訓，開始正式在公司內全面運行。
C. 模擬負責一個基於web的圖書管理系統軟體的開發，問： 應該如何分解此項目所應該包括的工作請做一個WBS
頂層分解至少要有以下內容：
1.用戶管理。
2.圖書管理。
3.借還登記。
4.圖書查詢。
5.圖書預定。
6.系統設置。
以上是最頂層的，每個頂層問題又可以繼續細分，例如 借還登記 又可以分為以下問題：
1.借書登記
2.還書登記
3.查看借閱情況
4.過期罰款。
一層層分解，問題分解到一個問題一個工程師能在一個里程碑內完成就無需再繼續分解了。
D. 未來web開發的趨勢是什麼
現在，Web開發世界在不斷變化，趨勢也在不斷變化。有時，這些趨勢的變化速度遠遠快於它們的使用速度。要保持領先，就必須關注最新的流行趨勢、更新、技術和方法。此外，了解趨勢並隨時了解周圍發生的事情對於web開發是非常必要的。
E. web前端項目開發流程
前端前景是很不錯的，像前端這樣的專業還是一線城市比較好，師資力量跟得上、就業的薪資也是可觀的，學習前端可以按照路線圖的順序，
0基礎學習前端是沒有問題的，關鍵是找到靠譜的前端培訓機構，你可以深度了解機構的口碑情況，問問周圍知道這家機構的人，除了口碑再了解機構的以下幾方面：
1. 師資力量雄厚
要想有1+1>2的實際效果，很關鍵的一點是師資隊伍，你接下來無論是找個工作還是工作中出任哪些的人物角色，都越來越愛你本身的技術專業前端技術性，也許的技術專業前端技術性則絕大多數來自你的技術專業前端教師，一個好的前端培訓機構必須具備雄厚的師資力量。
2. 就業保障完善
實現1+1>2效果的關鍵在於能夠為你提供良好的發展平台，即能夠為你提供良好的就業保障，讓學員能夠學到實在實在的知識，並向前端學員提供一對一的就業指導，確保學員找到自己的心理工作。
3. 學費性價比高
一個好的前端培訓機構肯定能給你帶來1+1>2的效果，如果你在一個由專業的前端教師領導並由前端培訓機構自己提供的平台上工作，你將獲得比以往更多的投資。
希望你早日學有所成。
F. 開發一個WEB項目的流程是怎樣的
首先了解項目需求，形成項目需求文檔
根據web項目未來的運行方式和場景選擇web運行伺服器，資料庫以及開發語言，還有支持的瀏覽器最低版本
小型的web項目最好邊開發邊和用戶交流，以盡可能滿足用戶需求
大型的web項目最好能將需求讓用戶確認，便於未來需求修改時評估修改成本或以合適理由拒絕修改
小型組網測試。小范圍內測試web項目的功能和交互方式。
壓力測試。如果web項目的使用人數將來會非常大，可能要找工具對該項目進行壓力測試。
試運行。試運行也可和前期測試相結合。
正式上線。
後期維護。
G. web開發解釋
「web 開發」是在網際網路www或者在區域網a private network上建立站點的各種方法的寬泛總稱。
web 開發可以從 開發一個最簡單的純文本的靜態單頁面 到 很復雜的基於web的internet 應用、電子商
務、和社交網路服務。一個更綜合性更完善性的歸納可以把web 開發分為為：
web 設計，
web 內容開發，
客戶端聯絡，
客戶端/伺服器端 腳本開發，
web 服務，
網路安全配置， 和
電子商務開發（比如支付服務）。
（相關詞條還有更深層次的解釋，有空我可以後續學習並翻譯出來）
在web 專業領域，「web 開發」一般是指 在網站建設中，那些無關頁面設計的工作：寫 Markup 標記語
言和寫代碼。
對於大的組織或公司，web 開發團隊可以由幾百個開發者（web開發人員）組成。小點的組織只需要單一
的長期工或者合同制的web master, 或者兼職。比如 圖形設計， 信息系統 工程人員。web開發會是幾個部門之
間的協同工作，而不是某個特定的designated部門的某個業務區域（domain）。
H. web開發過程中的各階段
（1）Web分析
基於Web的應用系統的需求分析是很重要的活動,需要一個系統而嚴密的方法. 根據Web特性和Web應用的特定需求,需要採用更為開放、靈活的需求分析方法.與傳統軟體過程的分析不同,Web分析階段不但要分析Web系統本身的功能和性能,還要對可能的用戶群體進行分析和調查.
（2）Web設計
Web設計不但包括功能設計和性能設計,還要包括頁面風格設計,包括頁面的主色調、頁面框架結構、文字顏色搭配、動畫和圖片的放置等.
有效的Web站點設計需要注意可用性,要把基於Web的系統設計成易於導航,吸引人和有用.現在,比較流行的Web設計方法是以用戶為中心的設計[4].
(3) Web開發
Web開發過程包括後台資料庫程序的開發、頁面程序的編寫和所有網頁的製作.在設計階段決定的Web框架基礎上,進行具體的頁面設計和製作.把內容提供人員的內容連接到具體的頁面.
一個Web工程過程必須包含多種類型的開發人員,要保證這些人員都能很好地理解自己在項目開發中的作用和職責,當有重疊發生時,應該要從整個項目角度找出解決方法.
(4) Web測試
在Web工程過程中,基於Web系統的測試、確認和驗收是一項重要而富有挑戰性的工作.基於Web的應用系統的測試與傳統的軟體測試不同,不但需要檢查和驗證是否按照設計的要求運行,而且還要評價系統在不同用戶的瀏覽器的顯示是否合適.重要的是,還要從最終用戶的角度進行安全性和可用性測試.因此,我們必須為測試和評估復雜的基於Web的系統,研究新的方法和技術.
（5）Web發布
Web發布階段主要是把開發完成,經過初步測試的Web應用系統傳送到Web站點上,供用戶瀏覽和使用.
(6) Web更新、支持和管理
與傳統的軟體系統不一樣,Web系統是需要經常更新的.這種更新包括細微的變化到大規模的變化,可以是頁面內容的刷新、也可以是整個頁面結構框架的更新(例如：整個主頁結構的變化、增加或變更一個欄目).正是因為這種改變是經常存在的,所以大型Web應用系統的管理是一項艱巨的任務.對每一種變化,無論大小,都需要以一種合理的,有控制的方式進行處理.我們可把經實踐證明了的軟體配置管理（SCM）的概念、原理和方法用到Web管理中.
I. 請教公司里web開發的流程
首先策劃出文案，然後設計出效果，通過後製作切圖做頁面，前後台可以同時做，套頁面應該是把任憑做的html靜態頁與程序員開發的後台綁定起來
J. web前端開發項目過程
老闆或甲方是一個需求的真正發起者，也是一個基礎idea的夢想師，產品是需求專業化梳理或進行有效評估細化需求負責的，
而設計是前端的上游，前端是設計的下游。設計的工作目的是把產品宏觀的思維結果進行專業的處理，因為按一般的習慣，產品最終的結果是原型圖，而原型圖可以理解為設計的草圖，
對真正的用戶來說，這個草圖過於簡單或不符合使用的操作習慣，所以需要設計師進行專業的處理，比如顏色搭配，布局分隔，有時候還兼交互的一部分工作，設置用戶與頁面發生交互的預訂流程，
那有人問，不需要設計不行嗎？直接讓前端寫頁面不就得了，還需要麻煩設計師來做個圖出來。
因為這里邊有一個成本風險控制的一個理念，因為在前期，尤其是設計，主觀感受大於理性的思考，所以每天的結果都不一樣，所以需要設計師去消化掉這部分主觀感受帶來的誤區，
而且從成本上來講，有些場景設計師改圖比改代碼要容易控制一些。
設計師的結果是psd文件，他是很多個圖層疊加在一起的結果，而前端的工作結果html頁面，是把很多圖層上的效果，有機的用html組織起來的過程。
前端是把轉化後html交給下游服務端開發工程師，或叫後台開發，這個html里邊包括一些交互的js文件等。總的來說前端是一個承前啟後的崗位。
也有的公司把前端的責任放大，負責整個前台view層頁面的開發，這樣的好與壞在前面的文章中已經探討過就不一一細表了。
我們以前基本的流程是，領導或甲方提出需求，然後產品分析需求，並且根據需求畫出原型圖，然後根據原型圖出設計稿。
出完設計稿團隊評審，過後交與前端製作靜態頁面，然後靜態頁面，交與設計審核，過後交給開發人員，進行動態數據的添加。
添加完之後，發布測試環境，產品測試領導審核，成功後，直接發布產品環境。或進行版本迭代。
這是整個的一個設計，開發，部署的流程。
根據前面的，在補充一下，前面的所有流程中的靈魂是原始需求提出者，但人隨著客觀條件的變化，思維認識會有所不一致，
所以產生了文檔，文檔是貫穿整個流程的一個靈魂。
而產品是整個流程中文檔的編寫者，因為產品最能接觸最原始的需求，對需求的理解更深刻或專業，所以他會有一個文檔出來。
這個文檔是需要交付給設計，讓設計在設計過程中進行參考。
前端看的另外一個文檔。交互設計師出交互文檔，一般的公司沒有交互設計師那就是由產品來出的交互文檔。
有的交互不過於復雜，就沒有文檔，只是郵件。
有時候說，不要這個郵件行不行，那怕是最簡單的原始東西，沒有文件或郵件是不能做一個後期測試回溯的依據。
產品文檔表示頁面的流轉或數據的走向，交互文檔描述頁面復雜的交互或各個用戶表單與用戶發生的各種互動。
另外2個是，要架構師或項目經理出的需求文檔，需求文檔是對整個項目的歷史背景，系統開發軟硬體要求，或版本信息，等等。
另外一個是由服務端工程師提供的介面文檔，這里邊包括一些請求類型，傳參的數目與鍵名，還有服務端返回的參數名約定等等的，這些文檔是開發中的靈魂，也是以後測試回溯的標准或依據。