游泳場項目總結-flym的eye-iteye技術網站
2011年09月01日
十一終於完了,進入到新的項目.終於有時間來總結一下做的一個游泳場的項目了.從項目開始到現在,已經三個月了.中間有很多次想要將這個東西寫下來,始終沒機會.現在有時間,好好想一下,也算是對自己的一個總結.
先說一下這個項目,是一個游泳場的收費系統,類似於公交車的卡系統.操作人員可以通過終端進行售票,然後用戶憑票在游泳池門口驗票進入;同時,也可以通過操作人員出售可以多次使用的IC卡,在游泳池門口通過刷卡器刷卡進入.這個系統的使用者分銷售員和驗卡票員,且游泳場分佈在不同的地方.故需要作成一個聯網的模式,以便進行數據同步.
因此這個項目從一開始就分爲兩個部分,卡和票.
票通過銷售終端銷售出去(用票打印機打印出來),在消費端由驗票員驗票進入.由於硬件條件限制,票打印機就是一般的打印機,沒有任何防僞標記,且驗票員由於水平原因也無法進行驗證真僞,故設計爲一個通過機器驗票進入的方式,即通過掃描儀的方式.將條形碼打印在票上,在消費時通過掃描條形碼進行驗證.
卡則是通過銷售終端根據用戶的類型辦理不同的卡(不同卡的消費方式不一樣,如折扣,金額,次數,時間).之後,在消費終端,通過將卡放在讀卡器上進行讀卡,對消費數據進行處理之後放行用戶.
這個項目先是由一位同事在弄,後來由於出現了金額數據上的原因.導致客戶對系統產生了不好的反應,因此由我來進行重新設計並編碼.要求的時間爲15天,而實際上用了30天.且說說前個同事在碰到的問題: 前期需求不太規範.由於客戶是個行政單位,在這個項目實施的過程之中,客戶單位行政上發生了變化.導致負責這個項目的人員發生了變化,而導致需求臨時變化.
設計及經驗上考慮不足.未考慮到此個項目在數據上的安全及完整.而在進行一些數據結構上的設計時,有些關鍵性的數據並沒有出現在對象屬性中,如消費和銷售的時間.
程序編碼不嚴謹.在對一些時間的處理上,未考慮到實際系統中的運動環境與想象中的差異,而任意作出一些判斷.在對銷售和消費時間的處理上,取值的時間爲客戶端機器時間而不是服務器時間而導致當兩者時間不一致時出現了銷售和消費時間與真實時間不一致的問題.
設計不充分,未考慮到擴展.在項目運動中,客戶根據實際要求,提出一些需要限制的條件或者消費卡類.由於前期未考慮到這部分,而後面在要增加此功能時,對於前者只能在數據庫中增加一個字段,而對於後者,只能通過修改程序代碼來解決.這就導致程序代碼判斷字段越來越多,且越來越複雜.或者,一直不能讓軟件能夠適應客戶的變化需求.
需求的更改欠考慮.在項目中,涉及到一個操作用戶登陸問題.當天操作用戶已打印財務數據時,就不能再登陸系統.這個需求在程序開發初期,就已經被內定爲一個重要的限制.而在項目運行期間,用戶的一句話讓主開發同事輕易就修改了這個設定,而沒有考慮到修改之後產生的後果,以致於後來在操作人員的金額數據上產生一個糾紛,並由於這個設定的修改和前面的時間問題,使得某操作人員在上交金額和實際統計金額有差異時,有相當的理由來爲自己開脫.
對用戶數據不夠重視.這個是最重要的問題.由於對整個系統的完整性未欠考慮,並沒有考慮到用戶數據的重要性.當出現一些數據上的不一致時,直接通過修改數據庫數據以達到一致的效果.而修改的數據卻是用戶的金額類數據,且在修改時讓客戶在旁邊觀看,以致於到後來客戶都明白做的行爲代表什麼並且指導同事修改哪些數據.這樣的結果,直接導致用戶金額數據的正確性受到質疑.以造成最後,用戶對數據的正確性表示懷疑.這個是最重要的問題.
當出現這些問題之後,公司要求整個項目重新設計並編碼.由我來進行負責,所以這個項目從一開始就是一個救火性質的項目.
在設計中,根據現有客戶提出的問題,進行整體上的重新考慮,並重新開發了系統.在開發中,卡這部分進行了重新考慮.由於前個設計,卡這部分由一位delphi同事以控件的形式內嵌於界面上(這個項目是bs系統),而導致在需要改變卡一些定義數據時,需要對這個控件進行重新修改並重新在消費終端進行註冊.爲了修正這個問題,決定將卡部分邏輯代碼放在服務端來完成(前個設計是由控件在客戶端來完成),而控件只負責與硬件交互,取得IC卡信息和與讀卡器交互發出聲音.這樣就涉及到控件與其他進行交互的問題,主要是控件與js之間的雙向交互.控件向js發生命令,再由js根據命令及相應腳本信息向指定服務發生信息,將取回的數據根據結果來控制控件與硬件的交互(如發聲音).在網上找了半天,找到一個類似的方法,但用到實際中就出問題(界面是一個框架性iframe界面),而導致控件無法與實際界面取得交互.後來決定用apple的方式來進行處理,在網上也得到了apple與js之間的詳細交互,並實驗成功.在修改了相應代碼之後,終於使apple能夠工作了.便發聲部分還有些問題(主要是讀卡是一個連續的死循環模式,而發聲同樣要調用讀卡器,導致出現了佔用鎖方面的問題),後來鑽研了許久,終於以一種討巧的方式使得讀卡與發聲能夠近似地獨立工作,而不互相影響.
一個月後,新系統正式上線.在成功將舊數據轉到新系統中時,第二天就出現了新的問題.所有的讀卡都出現了問題,原因就在於原讀卡器提供的java動態庫在讀卡內碼(一個惟一編碼)時,出現了數據的溢出問題.原動態庫RD800提供的java DLL中,讀出的卡內碼以int數值返回,而實際中的數據卻是long型,而導致讀出數據與真實數據不能對應,而不能正確讀卡和刷卡.在通過與硬件廠商聯繫之後,終於拿到了新的dll庫(其實就是java的本地庫).更新之後成功運動了.
第一天,客戶根據前一個系統的使用習慣,對新系統提出了一些問題.不過都是些小小的界面及顯示性問題.馬上在公司修改之後,在第二天進行程序更新.這樣來回幾天,系統終於能夠完整地運行了.後來,根據用戶的要求,增加了一些新的功能,由於,在設計時已經考慮到了,故新系統中的數據結構完全能夠支持客戶的新需求,故增加的功能都能夠很好地和系統兼容運行.
整個系統,從我接手到最後客戶提不出更多的需求結束,已是3個月了.中間,也實實在在地接觸了客戶,瞭解了一些客戶的情況.也算是給一直從事程序開發的自己提供一些實際的用戶經驗.下面是我總結的一些: 不要把客戶的水平想得太高.最開始想到的客戶至少會使用電腦,而在實際中由於許多客戶都是臨時請來的,有的完全不懂電腦,連鼠標都不會用.所以在一些設計上,要考慮到用戶的水平,儘量減少客戶的操作.如,在消費終端,用戶只需要點擊一個就可以不再用鼠標而只用掃描儀和驗卡器來完成驗票和驗卡的一天操作了.
客戶不會看系統中的任何提示信息.在驗票中,要求驗的條碼長度爲13位(EAN-13).在一些特殊情況下,掃描儀會掃描出非13位的條碼,當界面出現alert形式的提示框(提示票條碼長度不足)時,用戶會直接認爲這是通過,而不理會此問題.這樣就導致了接下來的操作全部失效.最後,將這個警告信息以驗票失敗的形式放在界面上才解決這個問題.
客戶會把任何非程序問題歸結爲程序上的問題.在銷售終端的售卡處,要用於照相機用於採集消費者頭像.(這個硬件部分不由公司提供,公司只負責軟件部分).當用戶由於不規範操作,出現照相機使用不了或無法與電腦相連接時,第一想到的是程序出了問題,而不是操作上的問題.一旦出現問題,就打電話讓解決.我們倒成了電腦維護員了.
客戶經常會根據自己的使用提出新的需求,而不考慮此需求是否恰當.如前面的第5條,這些修改都是由用戶最先提出,後來又提出修改的.如果將客戶的需求全部不加分析的接收之後,當發生某些問題時,客戶永遠不會承認是自己的問題,而永遠會說是軟件本身的問題.這樣就使得當提出新的需求和修改時,我常常會先想想這個問題與設計中的一些約束是否違被.一旦出現衝突就馬上提出,並且讓用戶寫出明確的修改意見,並簽字.(前個系統,都沒有簽字,只是由客戶口頭說)
一定要嚴格控制需求的變化.一旦需求確定之後,就必須要將新的需求,往後推或者直接拒絕掉.不然,一個項目永遠沒有結束的時候,當然也永遠沒有驗收的時候.
現在這個項目已經全部完了,我也不想再趟這個混水了.差一點就陷在這個項目裏了.現在作了這些總結,希望在以後的開發中也給自己提個醒,沒出類似的錯誤.
有興趣的朋友,可以去看看這個系統.看看實際運行如何.地址:成都市猛追灣游泳場.
2011年09月01日
十一終於完了,進入到新的項目.終於有時間來總結一下做的一個游泳場的項目了.從項目開始到現在,已經三個月了.中間有很多次想要將這個東西寫下來,始終沒機會.現在有時間,好好想一下,也算是對自己的一個總結.
先說一下這個項目,是一個游泳場的收費系統,類似於公交車的卡系統.操作人員可以通過終端進行售票,然後用戶憑票在游泳池門口驗票進入;同時,也可以通過操作人員出售可以多次使用的IC卡,在游泳池門口通過刷卡器刷卡進入.這個系統的使用者分銷售員和驗卡票員,且游泳場分佈在不同的地方.故需要作成一個聯網的模式,以便進行數據同步.
因此這個項目從一開始就分爲兩個部分,卡和票.
票通過銷售終端銷售出去(用票打印機打印出來),在消費端由驗票員驗票進入.由於硬件條件限制,票打印機就是一般的打印機,沒有任何防僞標記,且驗票員由於水平原因也無法進行驗證真僞,故設計爲一個通過機器驗票進入的方式,即通過掃描儀的方式.將條形碼打印在票上,在消費時通過掃描條形碼進行驗證.
卡則是通過銷售終端根據用戶的類型辦理不同的卡(不同卡的消費方式不一樣,如折扣,金額,次數,時間).之後,在消費終端,通過將卡放在讀卡器上進行讀卡,對消費數據進行處理之後放行用戶.
這個項目先是由一位同事在弄,後來由於出現了金額數據上的原因.導致客戶對系統產生了不好的反應,因此由我來進行重新設計並編碼.要求的時間爲15天,而實際上用了30天.且說說前個同事在碰到的問題: 前期需求不太規範.由於客戶是個行政單位,在這個項目實施的過程之中,客戶單位行政上發生了變化.導致負責這個項目的人員發生了變化,而導致需求臨時變化.
設計及經驗上考慮不足.未考慮到此個項目在數據上的安全及完整.而在進行一些數據結構上的設計時,有些關鍵性的數據並沒有出現在對象屬性中,如消費和銷售的時間.
程序編碼不嚴謹.在對一些時間的處理上,未考慮到實際系統中的運動環境與想象中的差異,而任意作出一些判斷.在對銷售和消費時間的處理上,取值的時間爲客戶端機器時間而不是服務器時間而導致當兩者時間不一致時出現了銷售和消費時間與真實時間不一致的問題.
設計不充分,未考慮到擴展.在項目運動中,客戶根據實際要求,提出一些需要限制的條件或者消費卡類.由於前期未考慮到這部分,而後面在要增加此功能時,對於前者只能在數據庫中增加一個字段,而對於後者,只能通過修改程序代碼來解決.這就導致程序代碼判斷字段越來越多,且越來越複雜.或者,一直不能讓軟件能夠適應客戶的變化需求.
需求的更改欠考慮.在項目中,涉及到一個操作用戶登陸問題.當天操作用戶已打印財務數據時,就不能再登陸系統.這個需求在程序開發初期,就已經被內定爲一個重要的限制.而在項目運行期間,用戶的一句話讓主開發同事輕易就修改了這個設定,而沒有考慮到修改之後產生的後果,以致於後來在操作人員的金額數據上產生一個糾紛,並由於這個設定的修改和前面的時間問題,使得某操作人員在上交金額和實際統計金額有差異時,有相當的理由來爲自己開脫.
對用戶數據不夠重視.這個是最重要的問題.由於對整個系統的完整性未欠考慮,並沒有考慮到用戶數據的重要性.當出現一些數據上的不一致時,直接通過修改數據庫數據以達到一致的效果.而修改的數據卻是用戶的金額類數據,且在修改時讓客戶在旁邊觀看,以致於到後來客戶都明白做的行爲代表什麼並且指導同事修改哪些數據.這樣的結果,直接導致用戶金額數據的正確性受到質疑.以造成最後,用戶對數據的正確性表示懷疑.這個是最重要的問題.
當出現這些問題之後,公司要求整個項目重新設計並編碼.由我來進行負責,所以這個項目從一開始就是一個救火性質的項目.
在設計中,根據現有客戶提出的問題,進行整體上的重新考慮,並重新開發了系統.在開發中,卡這部分進行了重新考慮.由於前個設計,卡這部分由一位delphi同事以控件的形式內嵌於界面上(這個項目是bs系統),而導致在需要改變卡一些定義數據時,需要對這個控件進行重新修改並重新在消費終端進行註冊.爲了修正這個問題,決定將卡部分邏輯代碼放在服務端來完成(前個設計是由控件在客戶端來完成),而控件只負責與硬件交互,取得IC卡信息和與讀卡器交互發出聲音.這樣就涉及到控件與其他進行交互的問題,主要是控件與js之間的雙向交互.控件向js發生命令,再由js根據命令及相應腳本信息向指定服務發生信息,將取回的數據根據結果來控制控件與硬件的交互(如發聲音).在網上找了半天,找到一個類似的方法,但用到實際中就出問題(界面是一個框架性iframe界面),而導致控件無法與實際界面取得交互.後來決定用apple的方式來進行處理,在網上也得到了apple與js之間的詳細交互,並實驗成功.在修改了相應代碼之後,終於使apple能夠工作了.便發聲部分還有些問題(主要是讀卡是一個連續的死循環模式,而發聲同樣要調用讀卡器,導致出現了佔用鎖方面的問題),後來鑽研了許久,終於以一種討巧的方式使得讀卡與發聲能夠近似地獨立工作,而不互相影響.
一個月後,新系統正式上線.在成功將舊數據轉到新系統中時,第二天就出現了新的問題.所有的讀卡都出現了問題,原因就在於原讀卡器提供的java動態庫在讀卡內碼(一個惟一編碼)時,出現了數據的溢出問題.原動態庫RD800提供的java DLL中,讀出的卡內碼以int數值返回,而實際中的數據卻是long型,而導致讀出數據與真實數據不能對應,而不能正確讀卡和刷卡.在通過與硬件廠商聯繫之後,終於拿到了新的dll庫(其實就是java的本地庫).更新之後成功運動了.
第一天,客戶根據前一個系統的使用習慣,對新系統提出了一些問題.不過都是些小小的界面及顯示性問題.馬上在公司修改之後,在第二天進行程序更新.這樣來回幾天,系統終於能夠完整地運行了.後來,根據用戶的要求,增加了一些新的功能,由於,在設計時已經考慮到了,故新系統中的數據結構完全能夠支持客戶的新需求,故增加的功能都能夠很好地和系統兼容運行.
整個系統,從我接手到最後客戶提不出更多的需求結束,已是3個月了.中間,也實實在在地接觸了客戶,瞭解了一些客戶的情況.也算是給一直從事程序開發的自己提供一些實際的用戶經驗.下面是我總結的一些: 不要把客戶的水平想得太高.最開始想到的客戶至少會使用電腦,而在實際中由於許多客戶都是臨時請來的,有的完全不懂電腦,連鼠標都不會用.所以在一些設計上,要考慮到用戶的水平,儘量減少客戶的操作.如,在消費終端,用戶只需要點擊一個就可以不再用鼠標而只用掃描儀和驗卡器來完成驗票和驗卡的一天操作了.
客戶不會看系統中的任何提示信息.在驗票中,要求驗的條碼長度爲13位(EAN-13).在一些特殊情況下,掃描儀會掃描出非13位的條碼,當界面出現alert形式的提示框(提示票條碼長度不足)時,用戶會直接認爲這是通過,而不理會此問題.這樣就導致了接下來的操作全部失效.最後,將這個警告信息以驗票失敗的形式放在界面上才解決這個問題.
客戶會把任何非程序問題歸結爲程序上的問題.在銷售終端的售卡處,要用於照相機用於採集消費者頭像.(這個硬件部分不由公司提供,公司只負責軟件部分).當用戶由於不規範操作,出現照相機使用不了或無法與電腦相連接時,第一想到的是程序出了問題,而不是操作上的問題.一旦出現問題,就打電話讓解決.我們倒成了電腦維護員了.
客戶經常會根據自己的使用提出新的需求,而不考慮此需求是否恰當.如前面的第5條,這些修改都是由用戶最先提出,後來又提出修改的.如果將客戶的需求全部不加分析的接收之後,當發生某些問題時,客戶永遠不會承認是自己的問題,而永遠會說是軟件本身的問題.這樣就使得當提出新的需求和修改時,我常常會先想想這個問題與設計中的一些約束是否違被.一旦出現衝突就馬上提出,並且讓用戶寫出明確的修改意見,並簽字.(前個系統,都沒有簽字,只是由客戶口頭說)
一定要嚴格控制需求的變化.一旦需求確定之後,就必須要將新的需求,往後推或者直接拒絕掉.不然,一個項目永遠沒有結束的時候,當然也永遠沒有驗收的時候.
現在這個項目已經全部完了,我也不想再趟這個混水了.差一點就陷在這個項目裏了.現在作了這些總結,希望在以後的開發中也給自己提個醒,沒出類似的錯誤.
有興趣的朋友,可以去看看這個系統.看看實際運行如何.地址:成都市猛追灣游泳場.
