網站專案實施業務流程及規範(轉)
商務流程
一、 尋找客戶,確定網站開發意向。在與客戶交流的過程中,可能要向客戶展示以前實施的樣板專案,還可能要給客戶製作網站樣例(圖片及文字說明)。
二、 簽定網站專案開發合同。客戶方預付一定數量的款項。
三、 專案實施完畢,客戶交付全部專案款。
需求分析
一、 進行客戶計算機應用水平調查。
二、 確定客戶方專案負責人員。
三、 召開使用者需求調研會議(最少一次)
參加會議人員:
客戶方:領導,客戶方專案負責人,業務代表,技術員等。
我方:商務人員,專案經理,技術人員(儘可能都參加)。
討論的內容及成果:以使用者需求為中心,共同討論,產生網站的欄目規劃(用樹形圖表示),標出哪些是靜態頁面,哪些是動態頁面。制定網站的介面框架,包括首頁構圖,及各頁面間的鉤稽關係。這一步可能需要反覆迴圈迭代若干次,直到客戶滿意。
需求分析要考慮使用者的當前業務,還要適當考慮將來業務的擴充套件。需求分析記錄的資料必須可*。
需求分析必須針對使用者的現實需求,既不能隱瞞技術細節,欺騙客戶,也不能產生"過度需求",無限偏離公司的技術力量甚至產生一些"不可能"的需求。
需求分析的成果就是《專案需求說明書》。
四、雙方對《專案需求說明書》確認後簽字,作為下一步開發的技術依據。簽字的目的是確保使用者需求在專案實施期間的穩定性。因為需求的大量更改,甚至"無限需求",會大量增加開發成本,最終延誤工期,還會影響專案質量。
開發流程及規範
Web 開發的分散性和互動性,決定了 Web 開發必須遵從一定的開發規範和技術約定,只有每個開發人員都按照一個共同的規範去設計、溝通、開發、測試、部署,才能保證整個開發團隊協調一致的工作,從而提高開發工作效率,提升工程專案質量。
一、 專案的角色劃分
如果不包括前、後期的市場推廣和產品銷售人員,開發團隊一般可以劃分為專案負責人、程式設計師、美工三個角色。
專案負責人在我們中國習慣稱為"專案經理",負責專案的人事協調、時間進度等安排,以及處理一些與專案相關的其它事宜。程式設計師主要負責專案的需求分析、策劃、設計、程式碼編寫、網站整合、測試、部署等環節的工作。美工負責網站的介面設計、版面規劃,把握網站的整體風格。如果專案比較大,可以按照三種角色把人員進行分組。
角色劃分是Web專案技術分散性甚至地理分散性特點的客觀要求,分工的結果還可以明確工作責任,最終保證了專案的質量。分工帶來的負效應就是增加了團隊溝通、協調的成本,給專案帶來一定的風險。所以專案經理的協調能力顯得十分重要,程式開發人員和美工在專案開發的初期和後期,都必須有充分的交流,共同完成專案的規劃和測試、驗收。
二、 開發工具的選取
不象C/S結構程式開發,可以一門語言從頭到尾,你用Delphi,就是Delphi程式設計師,你用VC++,你就是VC程式設計師。B/S結構的Web開發工作,工具的選擇是一件痛苦的事情。從Windows到Linux,從IIS到 Apache,從J2EE到 .NET,從COM到.NET到EJB元件……還有 Asp、Asp.net、Jsp、Php、Perl、Javascript、Vbscript……
美工也輕鬆不了多少,什麼"網頁三劍客" "新網頁三劍客"、FrontPage、Photoshop、CorelDraw……誰都說自己是最強大的!
我們的經驗是,選用工具時最好是統一的,比如美工統一用DreamwaverMX製作網頁,程式設計師全部用文字編輯器書寫程式碼。統一工具的好處是可以保持同一個專案文件的一致性,便於開發人員的交流和文件的儲存。
但是也不必刻意強求一致,比如美工可以使用任何自己熟悉的圖形處理軟體,只要最後能生成瀏覽器支援的圖片就可以了。正是Web開發工具的多樣性,才成就了今天網際網路多姿多彩的局面。
只要程式設計師的純Html和 Javascript 程式碼的功夫足夠過硬,就能勝任最後的網站整合工作。
三、 專案開發流程
如果專案真正談下來了,就需要正式確定前階段的需求分析,該補充的步驟必須補上。然後進行詳細的總體設計,其實也基本是前階段工作的重複和完善。
產生各欄目資料夾的結構圖(一些公共資料夾如images、scripts、 styles等需要固定存放,共同呼叫)。
然後由美工根據內容表現的需要,設計靜態網頁和其它動態頁面介面框架,該切分的圖片要根據尺寸切割開來。給需要程式動態實現的頁面預留頁面空間。制定字型、字號、超級連結等CSS樣式等。
在美工設計頁面的同時,程式設計師著手開發後臺程式程式碼,做一些必要的測試。
美工介面完成後,由程式設計師新增程式程式碼,整合網站。
由專案組共同聯調測試,發現bug,完善一些具體的細節。
製作幫助文件、使用者操作手冊。向使用者交付必要的產品設計文件。
然後進行網站部署、客戶培訓。
最後進入網站維護階段。這一階段也可以不包括在該專案中,而作為公司的服務內容。
以上的每一部都會產生一些階段性成果,專案經理需要及時進行監督、稽核,發現問題及時糾正。
為了控制專案的進度,應當實施填寫"專案進度表"制度,即每天填寫工作日誌,記錄當天的工作細目和工作量,以及需要解決和已經解決的問題。
四、 一些技術規則
1, 資料庫命名約定(參考了"匈牙利命名法")
資料庫(Database):格式 [db]_[ desc]。
表(Table):格式 [tab]_[desc]。表名長度不能超過30個字元,單詞首寫字母大寫,多個單詞間不用連線符號。
欄位(Field or Column):格式f_[type]_[desc]。f:表明這是一個欄位名稱;type:可選,表明欄位型別,字元型為c,整型為i,邏輯型為b,貨幣型別為m,浮點型為f,日期型為d,時間型為t,二進位制為bl。如果型別為字元型,可以省略。desc:對欄位屬性的有意義的描述,可以用英語單詞、單詞縮寫、漢語拼音、欄位實際含義的拼音縮寫等,單詞之間可以用單詞首字母大寫軟分割(推薦),也可以用"_"隔開。舉例:
f_name (姓名)
f_c_ UserInfo 或 f_c_ User_Info
f_xm (姓名)
f_grp_id (組標識)
索引(Index):格式 [idx]_[desc]。
檢視(View):格式 [View]_[表A]_[表B]_[表C]…,其中View表示"檢視"。這個檢視由幾個表產生就用連字元"_"連線幾個表的名,如果表過多可以將表名適當簡化。
儲存過程:格式 [sp]_[表名]_[存取過程名(縮寫)],比如sp_User_Delete。
觸發器(Trigger):格式 [trg]_[d][i[_[desc]。trg 代表觸發器;d,i,u表明觸發器型別(Delete,Insert,Update)定義,書寫順序為d、i、u;desc是表的名稱,表明觸發器所在的表。
資料庫裝置(Database Device):格式 [dev]_[desc]。
約束(Constraint):格式 [cns]_[desc]。
2, SQL語句書寫規範
SQL語句中,SQL關鍵字全部大寫,其它的遵照"資料庫命名約定"。例如:
SELECT * FROM tabNewsInfo WHERE f_UserName=’’ ORDER BY f_i_autoid
3, 資料夾命名約定
公共資料夾:
/images 公共圖片
/styles 樣式表
/scripts 指令碼
/ftps 下載
/doc 網站相關素材、文件
/readme.txt 網站說明文件
/helps.htm 網站幫助文件
/mylogs.txt 網站維護記錄
其它欄目的命名,可以用拼音首字母簡稱,也可以用英文單詞。全部資料夾的含義在readme.txt檔案中說明。
4,物件及變數命名約定
每個變數名必須先定義,再使用。在ASP檔案的最開頭新增語句可以強制變數定義。程式碼塊必須採用縮排格式。每個函式前必須標明函式的功能、輸入引數、返回值的相關資訊。
變數型別 縮寫字首
String str 或 s
Integer Int
Date Dt
Object obj或 o
Boolean bol或 b
Byte Byt
Double Dbl
Error Err
Long Lng
Single Sng
5,圖形物件約定
圖片的格式:最後生成 jpg,gif,png,swf 格式的圖形檔案
圖片的位元組大小:最大不能超過30k
圖片的尺寸:根據需要確定,最好使用小圖片,大的圖片必須切割成小圖片使用。
圖片的留白:圖片的邊界不能留白,圖片只包含有效的色彩元素
6,媒體物件約定
流媒體的格式: asf,wmv,wma,rm,不建議使用 avi 格式的動畫檔案
7,頁面佈局的基本約定
中文段落必須有2個漢字的縮排。字間距採用預設大小。行間距為16pt~20pt。文字佈局必須留有"天""地""左""右",不能把版面佔滿。
頁面佈局必須保持色彩平衡。注意上下、左右的呼應。注意頁面的整體協調。提倡畫面和文字的融合,而不是畫面和文字的明顯分離。
要按照設計廣告的要求來設計網頁頁面 - 特別是一些產品展示性的頁面。
五、 一些經驗和教訓
1,能用靜態網頁表現的內容,儘量不用程式程式碼動態實現。
2,設計階段,必須和使用者進行充分的交流,完全、準確的瞭解使用者的需求。既不能歪曲使用者的意思,也不能一味迎合使用者的非正當需求,也不能對自己沒有把握的技術甚至不可能實現的技術誇下海口。需求分析是一個溝通、交流、引導、教育、鬥爭、妥協的過程。需求分析結果要有文字資料存檔。
3,技術引數必須瞭解準確。比如使用者的軟體平臺是linux系列,那你的系統就要考慮用Java或者 Php 加MySQL開發了,這時候你的ASP.NET技術就用不上了。
4,最好讓使用者對已經確定的需求內容簽字,蓋章。
5,任何交流,必須有書面記錄。對一些喜歡"健忘"-實際上是懶惰的開發人員,要求他必須每天花10分鐘寫工作日誌。
6,每個專案的有關文件,全部、統一集中歸檔。
[@more@]
一、 尋找客戶,確定網站開發意向。在與客戶交流的過程中,可能要向客戶展示以前實施的樣板專案,還可能要給客戶製作網站樣例(圖片及文字說明)。
二、 簽定網站專案開發合同。客戶方預付一定數量的款項。
三、 專案實施完畢,客戶交付全部專案款。
需求分析
一、 進行客戶計算機應用水平調查。
二、 確定客戶方專案負責人員。
三、 召開使用者需求調研會議(最少一次)
參加會議人員:
客戶方:領導,客戶方專案負責人,業務代表,技術員等。
我方:商務人員,專案經理,技術人員(儘可能都參加)。
討論的內容及成果:以使用者需求為中心,共同討論,產生網站的欄目規劃(用樹形圖表示),標出哪些是靜態頁面,哪些是動態頁面。制定網站的介面框架,包括首頁構圖,及各頁面間的鉤稽關係。這一步可能需要反覆迴圈迭代若干次,直到客戶滿意。
需求分析要考慮使用者的當前業務,還要適當考慮將來業務的擴充套件。需求分析記錄的資料必須可*。
需求分析必須針對使用者的現實需求,既不能隱瞞技術細節,欺騙客戶,也不能產生"過度需求",無限偏離公司的技術力量甚至產生一些"不可能"的需求。
需求分析的成果就是《專案需求說明書》。
四、雙方對《專案需求說明書》確認後簽字,作為下一步開發的技術依據。簽字的目的是確保使用者需求在專案實施期間的穩定性。因為需求的大量更改,甚至"無限需求",會大量增加開發成本,最終延誤工期,還會影響專案質量。
開發流程及規範
Web 開發的分散性和互動性,決定了 Web 開發必須遵從一定的開發規範和技術約定,只有每個開發人員都按照一個共同的規範去設計、溝通、開發、測試、部署,才能保證整個開發團隊協調一致的工作,從而提高開發工作效率,提升工程專案質量。
一、 專案的角色劃分
如果不包括前、後期的市場推廣和產品銷售人員,開發團隊一般可以劃分為專案負責人、程式設計師、美工三個角色。
專案負責人在我們中國習慣稱為"專案經理",負責專案的人事協調、時間進度等安排,以及處理一些與專案相關的其它事宜。程式設計師主要負責專案的需求分析、策劃、設計、程式碼編寫、網站整合、測試、部署等環節的工作。美工負責網站的介面設計、版面規劃,把握網站的整體風格。如果專案比較大,可以按照三種角色把人員進行分組。
角色劃分是Web專案技術分散性甚至地理分散性特點的客觀要求,分工的結果還可以明確工作責任,最終保證了專案的質量。分工帶來的負效應就是增加了團隊溝通、協調的成本,給專案帶來一定的風險。所以專案經理的協調能力顯得十分重要,程式開發人員和美工在專案開發的初期和後期,都必須有充分的交流,共同完成專案的規劃和測試、驗收。
二、 開發工具的選取
不象C/S結構程式開發,可以一門語言從頭到尾,你用Delphi,就是Delphi程式設計師,你用VC++,你就是VC程式設計師。B/S結構的Web開發工作,工具的選擇是一件痛苦的事情。從Windows到Linux,從IIS到 Apache,從J2EE到 .NET,從COM到.NET到EJB元件……還有 Asp、Asp.net、Jsp、Php、Perl、Javascript、Vbscript……
美工也輕鬆不了多少,什麼"網頁三劍客" "新網頁三劍客"、FrontPage、Photoshop、CorelDraw……誰都說自己是最強大的!
我們的經驗是,選用工具時最好是統一的,比如美工統一用DreamwaverMX製作網頁,程式設計師全部用文字編輯器書寫程式碼。統一工具的好處是可以保持同一個專案文件的一致性,便於開發人員的交流和文件的儲存。
但是也不必刻意強求一致,比如美工可以使用任何自己熟悉的圖形處理軟體,只要最後能生成瀏覽器支援的圖片就可以了。正是Web開發工具的多樣性,才成就了今天網際網路多姿多彩的局面。
只要程式設計師的純Html和 Javascript 程式碼的功夫足夠過硬,就能勝任最後的網站整合工作。
三、 專案開發流程
如果專案真正談下來了,就需要正式確定前階段的需求分析,該補充的步驟必須補上。然後進行詳細的總體設計,其實也基本是前階段工作的重複和完善。
產生各欄目資料夾的結構圖(一些公共資料夾如images、scripts、 styles等需要固定存放,共同呼叫)。
然後由美工根據內容表現的需要,設計靜態網頁和其它動態頁面介面框架,該切分的圖片要根據尺寸切割開來。給需要程式動態實現的頁面預留頁面空間。制定字型、字號、超級連結等CSS樣式等。
在美工設計頁面的同時,程式設計師著手開發後臺程式程式碼,做一些必要的測試。
美工介面完成後,由程式設計師新增程式程式碼,整合網站。
由專案組共同聯調測試,發現bug,完善一些具體的細節。
製作幫助文件、使用者操作手冊。向使用者交付必要的產品設計文件。
然後進行網站部署、客戶培訓。
最後進入網站維護階段。這一階段也可以不包括在該專案中,而作為公司的服務內容。
以上的每一部都會產生一些階段性成果,專案經理需要及時進行監督、稽核,發現問題及時糾正。
為了控制專案的進度,應當實施填寫"專案進度表"制度,即每天填寫工作日誌,記錄當天的工作細目和工作量,以及需要解決和已經解決的問題。
四、 一些技術規則
1, 資料庫命名約定(參考了"匈牙利命名法")
資料庫(Database):格式 [db]_[ desc]。
表(Table):格式 [tab]_[desc]。表名長度不能超過30個字元,單詞首寫字母大寫,多個單詞間不用連線符號。
欄位(Field or Column):格式f_[type]_[desc]。f:表明這是一個欄位名稱;type:可選,表明欄位型別,字元型為c,整型為i,邏輯型為b,貨幣型別為m,浮點型為f,日期型為d,時間型為t,二進位制為bl。如果型別為字元型,可以省略。desc:對欄位屬性的有意義的描述,可以用英語單詞、單詞縮寫、漢語拼音、欄位實際含義的拼音縮寫等,單詞之間可以用單詞首字母大寫軟分割(推薦),也可以用"_"隔開。舉例:
f_name (姓名)
f_c_ UserInfo 或 f_c_ User_Info
f_xm (姓名)
f_grp_id (組標識)
索引(Index):格式 [idx]_[desc]。
檢視(View):格式 [View]_[表A]_[表B]_[表C]…,其中View表示"檢視"。這個檢視由幾個表產生就用連字元"_"連線幾個表的名,如果表過多可以將表名適當簡化。
儲存過程:格式 [sp]_[表名]_[存取過程名(縮寫)],比如sp_User_Delete。
觸發器(Trigger):格式 [trg]_[d][i[_[desc]。trg 代表觸發器;d,i,u表明觸發器型別(Delete,Insert,Update)定義,書寫順序為d、i、u;desc是表的名稱,表明觸發器所在的表。
資料庫裝置(Database Device):格式 [dev]_[desc]。
約束(Constraint):格式 [cns]_[desc]。
2, SQL語句書寫規範
SQL語句中,SQL關鍵字全部大寫,其它的遵照"資料庫命名約定"。例如:
SELECT * FROM tabNewsInfo WHERE f_UserName=’’ ORDER BY f_i_autoid
3, 資料夾命名約定
公共資料夾:
/images 公共圖片
/styles 樣式表
/scripts 指令碼
/ftps 下載
/doc 網站相關素材、文件
/readme.txt 網站說明文件
/helps.htm 網站幫助文件
/mylogs.txt 網站維護記錄
其它欄目的命名,可以用拼音首字母簡稱,也可以用英文單詞。全部資料夾的含義在readme.txt檔案中說明。
4,物件及變數命名約定
每個變數名必須先定義,再使用。在ASP檔案的最開頭新增語句可以強制變數定義。程式碼塊必須採用縮排格式。每個函式前必須標明函式的功能、輸入引數、返回值的相關資訊。
變數型別 縮寫字首
String str 或 s
Integer Int
Date Dt
Object obj或 o
Boolean bol或 b
Byte Byt
Double Dbl
Error Err
Long Lng
Single Sng
5,圖形物件約定
圖片的格式:最後生成 jpg,gif,png,swf 格式的圖形檔案
圖片的位元組大小:最大不能超過30k
圖片的尺寸:根據需要確定,最好使用小圖片,大的圖片必須切割成小圖片使用。
圖片的留白:圖片的邊界不能留白,圖片只包含有效的色彩元素
6,媒體物件約定
流媒體的格式: asf,wmv,wma,rm,不建議使用 avi 格式的動畫檔案
7,頁面佈局的基本約定
中文段落必須有2個漢字的縮排。字間距採用預設大小。行間距為16pt~20pt。文字佈局必須留有"天""地""左""右",不能把版面佔滿。
頁面佈局必須保持色彩平衡。注意上下、左右的呼應。注意頁面的整體協調。提倡畫面和文字的融合,而不是畫面和文字的明顯分離。
要按照設計廣告的要求來設計網頁頁面 - 特別是一些產品展示性的頁面。
五、 一些經驗和教訓
1,能用靜態網頁表現的內容,儘量不用程式程式碼動態實現。
2,設計階段,必須和使用者進行充分的交流,完全、準確的瞭解使用者的需求。既不能歪曲使用者的意思,也不能一味迎合使用者的非正當需求,也不能對自己沒有把握的技術甚至不可能實現的技術誇下海口。需求分析是一個溝通、交流、引導、教育、鬥爭、妥協的過程。需求分析結果要有文字資料存檔。
3,技術引數必須瞭解準確。比如使用者的軟體平臺是linux系列,那你的系統就要考慮用Java或者 Php 加MySQL開發了,這時候你的ASP.NET技術就用不上了。
4,最好讓使用者對已經確定的需求內容簽字,蓋章。
5,任何交流,必須有書面記錄。對一些喜歡"健忘"-實際上是懶惰的開發人員,要求他必須每天花10分鐘寫工作日誌。
6,每個專案的有關文件,全部、統一集中歸檔。
[@more@]
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/7839396/viewspace-937395/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- JB的測試之旅-專案流程規範
- 專案中的 Git 使用規範 [轉]Git
- 【軟體設計】專案設計流程規範
- 前端規範之vue 專案規範前端Vue
- 軟體專案研發流程該怎麼規範
- 資料開發流程及規範
- 《專案經理指導手冊》規範篇5,任務規範
- ReactNative專案實踐編碼規範React
- 業務流程管理三段論之規範化
- 企業如何實施專案控制?
- 專案規範筆記筆記
- 前端專案git操作命名規範和協作開發流程前端Git
- CMDB實踐指南:專案規劃與實施策略解析
- 我的專案命名規範
- 專案規範-git commit 配置GitMIT
- 前端開發規範 從制定到實施前端
- 專案實施方案
- 個人專案開發規範
- 專案中的 Git 使用規範Git
- SpringBoot 專案規範筆記.2021Spring Boot筆記
- 淺談專案程式碼規範
- 專案實施過程
- 微服務架構大型電商專案開發流程及技術實戰微服務架構
- 利用husky實現前端專案自定義規範校驗前端
- 企業網站安全滲透測試服務範圍網站
- 測試流程與規範
- 專案可以怎麼規範Git commit ?GitMIT
- 如何規範化專案管理,提升效率?專案管理
- 印度和俄羅斯cos共同實施重大工業物聯網專案
- Sonata簽署業務轉型CRM專案
- 華為工單寶:助力製造業數字化轉型,透過專案管理實現售後服務自動化和規範化專案管理
- RPA專案的實施週期一般是多久?企業如何來估算RPA專案的實施週期?
- 測試流程規範--提測規範(釘釘、郵件)
- python大型專案開發規範_學習Python模組匯入機制與大型專案的規範Python
- (轉)豆瓣網前端開發規範之 【CSS】前端CSS
- 前端工具類專案規範化-使用TS前端
- 如何打造規範的開源專案workflow
- 團隊專案的Git分支管理規範Git
- 技術專案文件書寫規範指南