網站項目建設流程概述

網站項目建設流程概述

一.概念 
網站項目管理就是根據特定的規範、在預算範圍內、按時完成的網站開發任務。 
二.需求分析 
項目立項 

咱們接到客戶的業務諮詢，通過雙方不斷的接洽和了解，並經過基本的可行性討論夠，初步達成製做協議，這時就須要將項目立項。較好的作法是成立一個專門的項目小組，小組成員包括：項目經理，網頁設計，程序員，測試員，編輯/文檔等必須人員。項目實行項目經理制。 

客戶的需求說明書 

第一步是須要客戶提供一個完整的需求說明。不少客戶對本身的需求並非很清楚，須要您不斷引導和幫助分析。曾經有一次，我問客戶："您作網站的目的是什麼？"他回答："沒有目的，只是由於別人都有，我沒有！"。這樣的客戶就須要耐心說明，仔細分析，挖掘出他潛在的，真正的需求。 配合客戶寫一份詳細的，完整的需求說明會花不少時間，但這樣作是值得的，並且必定要讓客戶滿意，簽字承認。把好這一關，能夠杜絕不少由於需求不明或理解誤差形成的失誤和項目失敗。糟糕的需求說明不可能有高質量的網站。那麼需求說明書要達到怎樣的標準呢？簡單說，包含下面幾點： 

1.正確性：每一個功能必須清楚描寫交付的功能； 

2.可行性：確保在當前的開發能力和系統環境下能夠實現每一個需求； 

3.必要性：功能是否必須交付，是否能夠推遲實現，是否能夠在削減開支狀況發生時"砍"掉； 

4.簡明性：不要使用專業的網絡術語； 

5.檢測性：若是開發完畢，客戶能夠根據需求檢測。

三.系統分析 

--------------------------------------------------------------------------------

網站整體設計 


在拿到客戶的需求說明後，並非直接開始製做，而是須要對項目進行整體設計，詳細設計，出一份網站建設方案給客戶。整體設計是很是關鍵的一步。它主要肯定： 

1.網站須要實現哪些功能； 

2.網站開發使用什麼軟件，在什麼樣的硬件環境； 

3.須要多少人，多少時間； 

4.須要遵循的規則和標準有哪些。 


同時須要寫一份整體規劃說明書，包括： 

1.網站的欄目和版塊； 

2.網站的功能和相應的程序； 

3.網站的連接結構； 

4.若是有數據庫，進行數據庫的概念設計； 

5.網站的交互性和用戶友好設計。 


網站建設方案 


在整體設計出來後，通常須要給客戶一個網站建設方案。不少網頁製做公司在接洽業務時就被客戶要求提供方案。那時的方案通常比較籠統，並且在客戶需求不是十分明確的狀況下提交方案，每每和實際製做後的結果會有很大差別。因此應該儘可能取得客戶的理解，在明確需求並整體設計後提交方案，這樣對雙方都有益處。網站建設方案的包括如下幾個部分： 

1.客戶狀況分析； 

2.網站須要實現的目的和目標； 

3.網站形象說明； 

4.網站的欄目版塊和結構； 

5.網站內容的安排，相互連接關係； 

6.使用軟件，硬件和技術分析說明； 

7.開發時間進度表； 

8.宣傳推廣方案； 

9.維護方案； 

10.製做費用； 

11.本公司簡介：成功做品，技術，人才說明等。 


當您的方案經過客戶的承認，那麼恭喜你！您能夠開始動手製做網站了。但還不是真正意義上的製做，你須要進行詳細設計： 


網站詳細設計 


整體設計階段以比較抽象歸納的方式提出瞭解決問題的辦法。詳細設計階段的任務就是把解法具體化。詳細設計主要是針對程序開發部分來講的。但這個階段的不是真正編寫程序，而是設計出程序的詳細規格說明。這種規格說明的做用很相似於其餘工程領域中工程師常用的工程藍圖，它們應該 包含必要的細節，例如：程序界面，表單，須要的數據等。程序員能夠根據它們寫出實際的程序代碼。

四. 項目實施 

--------------------------------------------------------------------------------

總體形象設計 


在程序員進行詳細設計的同時，網頁設計師開始設計網站的總體形象和首頁。 

總體形象設計包括標準字，Logo，標準色彩，廣告語等。 首頁設計包括版面，色彩，圖像，動態效果，圖標等風格設計，也包括banner，菜單，標題，版權等模塊設計。首頁通常設計1-3個不一樣風格，完成後，供客戶選擇。 

記住：在客戶肯定首頁風格以後，請客戶簽字承認。之後不得再對版面風格有大的變更，不然視爲第二次設計。 


開發製做 

到這裏，程序員和網頁設計師同時進入全力開發階段，須要提醒的是，測試人員須要隨時測試網頁與程序，發現Bug馬上記錄並反饋修改。不要等到徹底製做完畢再測試，這樣會浪費大量的時間和精力。項目經理須要常常瞭解項目進度，協調和溝通程序員與網頁設計師的工做。 


調試完善 


在網站初步完成後，上傳到服務器，對網站進行全範圍的測試。包括速度，兼容性，交互性，連接正確性，程序健壯性，超流量測試等，發現問題及時解決並記錄下來。 

爲何要記錄文檔呢？其實本軟件工程自己就是一個文檔，是一個不斷充實和完善的標準。經過不斷的發現問題，解決問題，修改，補充文檔，使這個標準愈來愈規範，愈來愈工業化。進而使得網站開發趨向規範，趨向合理。 


宣傳推廣 


宣傳推廣的基本方法有： 

1.網頁裏設置適當的META標籤； 

2.各搜索引擎登陸； 

3.準備新聞稿件在各新聞公告板發表； 

4.合理使用Email郵件列表； 

5.廣告條交換； 

6.付費廣告。 

至此，網站項目建設完畢，將有關網址，使用操做說明文檔等提交客戶驗收。若是須要維護，另行簽訂維護項目。 


維護 


網站成功推出後，長期的維護工做纔剛剛開始，咱們須要作到的是 

1.及時響應客戶反饋；例如能夠採起Email自動回覆功能，而後在1-3個工做日裏解決問題，再次回覆； 

2.網站流量統計分析和相應對策； 

3.儘可能推廣和使用您的網址； 

4.網站內容的及時更新和維護。 


五.遵循的規範 


1.網站建設目錄規範 

2.網站文件命名規範 

3.網站建設尺寸規範 

4.網站首頁head區代碼規範 

5.網站鏈接結構規範

隨着技術的不斷髮展和用戶對網站功能性的需求不斷提升，現在網站項目的設計已經不能再僅僅簡單地利用靜態Html文件來實現，與前幾年網站設計由一兩名網頁設計師自由的創做相比，網站項目的設計和開發愈來愈像一個軟件工程，也愈來愈複雜，網站項目的設計和開發進入了須要強調流程和分工的時代，創建規範的、有效的、健壯的開發機制，才能適應用戶不斷變化的須要，達到預期的計劃目標。 

　　網站項目管理（WPM）的含義爲Web-based Project Management，即以Web 應用程序爲主要表現方式的架構來進行的項目設計及管理，這樣的架構中包含了瀏覽器、網絡和Web 服務器等關鍵主體，主要體如今網站設計、以瀏覽器爲客戶端的Web應用程序開發（例如信息類網站、網上商店、虛擬郵局、客戶關係管理。）等項目管理中。 

　　在本文中，筆者將網站項目管理（WPM）與軟件工程的統一過程管理（RUP）進行參照比較，並結合實際工做經驗，力求將網站工程管理（WPM）的角色、分工、流程進行完整的闡述，使網站項目管理逐漸走向規範化。 

　　按照筆者的經驗，網站項目管理能夠分爲如下六個階段進行控制： 

1. 需求分析及變動管理 

2. 項目模型及業務流程分析 

3. 系統分析及軟件建模 

4. 界面設計、交互設計及程序開發 

5. 系統測試和文檔編寫 

6. 客戶培訓、技術支持和售後服務 

　　須要說明的是，這些階段雖然具備必定的延續性，可是並不是徹底隔斷的，例如需求變動管理和測試工做、文檔編寫都是貫穿整個項目過程的，許多工做時交叉進行或同時進行的。 


（二）項目模型及業務流程分析 


　　網絡技術的應用所產生的電子流程工做方式既不能完全更改傳統的工做流程，也不是對傳統工做流程的簡單複製，而須要對傳統的工做流程進行合理的優化、改進和重組。 


本章包括如下內容： 

一. 編寫項目模型文檔，使全部人都一目瞭然 

二. 業務流程分析員進行流程設計 

三. 界面工程師設計用戶界面原型 

四. 以用戶爲中心的設計思考 

五. 製做設計計劃書 

六. 總結 


一. 編寫項目模型文檔，使全部人都一目瞭然 


　　爲何要製做項目模型文檔？ 

　　一般用戶提出的需求是凌亂的，不完整的，甚至是不正確的，並且更細緻的需求常常是在項目開發進行中才被挖掘發現的，這對於開發人員來講是個極其困擾的問題。那麼，在進行需求分析後製做項目模型文檔，能在項目進入開發前，雙方對即將要開始完成的項目的結果有個共同的認識，並提前暴露可能出現的需求變動，那麼將大大提升開發的效率和質量。 

　　缺少經驗的項目人員每每在接受任務後火燒眉毛地進行系統分析和開發，而不肯意多一點時間在和客戶反覆推敲項目需求和模型，開發過程當中想固然地憑空爲客戶作了不少假想，費了九牛二虎之力卻吃力不討好，可想而知，在不知道終點在哪裏的馬拉松比賽中，你會跑到哪裏去？！ 

　　所以在確認了客戶的初步需求之後，業務人員應該進行項目模型的設計描述。 

　　首先，咱們要定義一下詞彙表，並不是每一個客戶或者項目小組成員都可以明白"用戶"、"角色"、"用例"之間的差異，也不見得都能很好地理解"通道"、"前臺"、"後臺"究竟是什麼含義，爲了讓項目模型文檔使每一個瀏覽者正確地理解，定義詞彙表是很是須要的，尤爲是面對傳統行業初次進行信息化設計的用戶。 

　　 

　　模型描述採用最天然的語言進行描述，這份文檔是對需求分析報告的進一步描述。使得客戶表明、項目經理、開發人員對即將展開的項目經過項目模型的描述產生最直觀的印象，並針對關鍵的問題進行討論並達成統一認識，好比功能要求、性能指標、運行環境、投資規模等等。
二. 業務流程分析員進行流程設計 


　　業務流程分析員的人員應該善於簡化工做，擔任此角色的人員中必需要有具有廣博的專業領域知識，而且具備良好的溝通技巧。 

　　業務分析人員重點須要協助客戶將需求進行概括分析，查找出全部的業務主角，肯定業務主角後，每一個主角的相關活動及流程應清晰地制定出來，最終設計出邏輯視圖、用戶界面示意圖。好比一個電子商店系統，除了系統管理員、業務經理、業務員、物流配送員、客戶服務人員等角色之外，可能還存在外部協做單位的不一樣角色，好比供應商、分銷商、廣告客戶，還有購買用戶，甚至再細分爲普通消費用戶、VIP消費用戶、集團消費用戶等等，每一類角色參與系統活動時的入口和流程都有所不一樣，經過邏輯圖和示意圖，業務流程分析員將系統的機構簡要明確地進行描述。 

　　在進行業務流程設計，須要注意如下事項： 

* 調查用戶網絡環境和配置，使架構設計師可以制定合理可行的系統架構； 

* 調查用戶偏好和技能水平，這將直接影響到項目開發的深度和用戶界面的設計； 

"雖然開發人員和管理人員很容易自認爲他們瞭解用戶須要，但實際狀況經常不是這樣。人們每每關注於用戶應該如何執行任務，而不是用戶偏好如何執行。多數狀況下，偏好問題不只僅是簡單地認爲已掌握了用戶須要，儘管這自己就很值得研究。偏好還要由經驗、能力和使用環境決定。" 

* 預測並制定系統的性能指標，爲測試人員編寫測試計劃提供依據。 

許多項目設計中比較重視功能的實現，測試階段看似知足了客戶的需求，但一旦投入使用的時候，便會發現性能上面臨着一個個瓶頸。客戶因爲對專業知識的瞭解程度有限，也每每忽略了這方面要求，所以爲了不往後陷入糾紛，事先預測並制定性能指標是很是重要的。 


三. 界面工程師建立用戶界面原型 


　　爲了在實際系統開發投入以前，建立用戶界面模型是很是重要的，開發原型的成本遠遠低於實際開發的成本，在項目初期，建立完整的用戶界面揭示和測試系統的全部功能和可用性，並可以使客戶表明參與討論及修改，能夠大大提升項目的成功概率。 

　　建立正確可行的原型之後，系統分析、設計及代碼的編寫都必須遵守原型進行，確保構建的系統是正確的，測試人員和客戶也可以在開發過程當中即實時地參與檢查，能夠有效地保障了項目的質量。 

　　根據業務流程分析員所提供的流程分析邏輯圖及示意圖，界面設計工程師開始設計製做用戶界面原型，目前這個階段，對於界面設計人員來講尚未進入精細設計的階段，因此最重要的是將業務流程完整地表現出來，並和客戶就設計風格，設計規範進行確認和定義。 

　　界面工程師在充分理解客戶需求和全部的業務流程以後，利用合理的佈局設計用戶界面。好比網站的首頁風格、首頁須要顯示的各個元素、導航的分類和表現方法、各種業務角色的入口等等。 

　　在此須要注意的是，用戶界面不只僅是網站訪問者所瀏覽的界面，也包括了特殊用戶、管理員、業務夥伴等不一樣的用戶界面，甚至還有提示界面、警告界面、出錯界面等等，設計完整的用戶界面原型不只可以使客戶及測試人員更容易明確需求，也對項目的質量起到不可忽視的做用。
四. 以用戶爲中心的設計思考 


　　不管項目設計開發人員的水平多麼精尖，畢竟不是系統的最終用戶，最大限度地知足客戶的須要纔是關鍵，系統設計人員每每口頭上掛着以用戶爲中心的口號，而實際上工做中又在大量地假想，或是出於懶惰或是出於條件限制，對於未來使用系統的不一樣用戶來講均可能產生意想不到的障礙。 

　　真正作到以用戶爲中心，就要先放棄沉澱在腦子裏的經驗和想象，到客戶工做的地方去、觀察記錄客戶如何工做、而後與客戶談論他們的工做。 

　　在團隊拓展訓練中有一項叫作"盲人方陣"的課程，能夠想象一羣什麼也看不見的人如何把一根長繩子拉成正方形景象嗎？目中無人的人會懂得傾聽和服從嗎？咱們不能假設用戶究竟是個健全人仍是盲人，也不能假想用戶應該會怎麼作不應會怎麼作，只有去仔細觀察和溝通，才能制定出真正符合用戶須要的計劃。 

　　有專家提出：開發人員應決定用戶的組成，並讓用戶儘量早地涉入，並提出了幾種熟悉用戶、他們的任務以及需求的方法： 

* 與用戶交談 

* 到辦公地點拜訪用戶 

* 觀察用戶工做 

* 將用戶工做錄像 

* 瞭解工做組織 

* 自我嘗試 

* 使用戶在工做時邊想邊說 

* 讓用戶參與設計 

* 在設計小組中包括專家級用戶 

* 執行任務分析 

* 利用調查和問卷 

* 制定可測試的目標 

　　在有可能的狀況，在需求和流程設計中努力作到精確、客觀和細緻，不但能保證系統開發的質量和成熟度，也會使你獲得客戶高度的滿意和信任，爲從此更多的業務合做敞開大門。
五. 製做設計計劃書 

　　到了這個階段，能夠說掌握了客戶的需求並對計劃實施的系統開發有了清楚地認識，與客戶之間達成了共識，那麼在進入下個階段的工做時，製做設計計劃書是很是必要的。 

　　設計計劃書是全面描述整個系統的全貌，做爲系統分析、測試人員工做的基礎，同時也是客戶驗收的標準，做爲業務合同的內容之一，所以，應該仔細謹慎地撰寫設計計劃書。 

　　根據項目的不一樣，設計計劃書的內容或許有所不一樣，如下筆者提供一份樣本供你們參考，該份樣本基本涵蓋了須要在計劃書中進行確認和描述的核心要素。
--------------------------------------------- --------------------------
<項目名稱>
項目計劃書
版本<x.x> 

歷史修訂紀錄
---------------------------------------------------
日期 | 版本 | 說明 | 做者 |
---------------------------------------------------
y/m/d| <x.x> | 修訂狀況 | <姓名> |
---------------------------------------------------
| | | |
---------------------------------------------------
| | | |
---------------------------------------------------
| | | |
---------------------------------------------------

目錄
1。項目概況
1。1 客戶資料
1。2 項目背景
1。3 項目前景
2。需求分析
2。1用戶腳色
2。2關鍵技術
2。3網站結構
2。4形象定位
3。整體方案
3。1系統框架
3。2拓撲結構
3。3部署計劃
4 配置及報價
4。1網絡環境
4。2硬件配置
4。3軟件配置
4。4其餘配置
5。實施步驟及週期
6。系統功能祥述
7。技術保障及支持
8。升級培訓及服務
9。關於我司
10。聯絡方式
11。附件列表
11。1項目模型文檔
11。2業務流程分析文檔
11。3用戶界面設計圖
12。版權聲明

--------------------------------------------------------------------
六. 總結 

　　在本階段的工做過程當中，核心的任務是經過上個階段的需求分析，進行項目模型設計和業務流程分析，並製做用戶界面原型獲得用戶的確認，最終完成雙方承認的《設計計劃書》，做爲下一階段系統設計和軟件建模的依據。 

如何高質量地完成業務流程分析階段的工做，筆者總結的經驗以下： 

* 真正以用戶爲中心的設計，到客戶的實際工做環境中觀察和記錄； 

* 仔細查找各類業務主角，並表述不一樣主角的各類操做流程步驟； 

* 簡化需求，將客戶的需求概括整理，抓住核心問題； 

* 細化需求，針對核心問題，模擬用戶角色，進一步確認流程和規範； 

* 認真制定設計計劃書，爲下階段的工做打好基礎。 

 

分類:  項目管理