完成應用程式後還要許多動作,進行測試,按照測試文件一步一步的動作,並記錄下來,由其是我們開發的pocket pc 給別人的檔案也必要要給清楚東西,最好自己先試過之後,在壓縮起來給別人,當一切都ok了之後才給soucrce code.
文件真的很重要
星期日, 7月 31, 2005
專案執行
這次有一個接case的機會,讓我加加經驗值,做這個東西之前,我不會c#,不會sybase,沒有database的實戰經驗,只有爽快而已,不過這是一次很重要的經驗,首先整個組合裡沒有人接過這樣的case,也沒接過,做這樣的事,似乎膽子太大了點.
拿到這開發文件後有許多注意的要點在這之後要慢慢的記下來:
首先這是個很多畫面的應用程式,而真的需要這樣多的人力去開發嗎?第一次用C#,第一次拉那麼多的試窗介面,我們浪費很多的時間去試了很多東西,才得到了一些結果.
畫面分析:
畫面是很多沒錯,但是功能都差不多,而且如果一開始對這些都很默生的話,那必須集中人力去針對某些細節去討論,當完成了一個基礎的雛形後,就開始為程式的命名方式,寫做方法,做個規化,當討論到一個結果後就可以針對類似的畫面做苦功了,一個人做苦功常常會比分出兩三個人快,類似頁面,也比較能掌握命名方式.
分工合作:
由一個主要的人去領導,去掌握是一見重要的事,很多人只會做,就像球員一樣,但是缺少一個教練,後衛,跑壘指導員的話,多多少少是盲目的,而這樣的人不一定要是一個很會做的人,但是他是要能看出缺點.問題.和指導出方向,所以經驗是很重要的.
文件的寫作:
大部份的人都還沒有寫做文件的習慣,我也是!!雖然說能把事情解決,但是將文件製造出來卻是個問題,有可能寫出來的東西七零八落,這必須多學習一些相關的課程才能去好好的改善.首先機本上由開發文件所製造出的問題,由條例式的列出,並向PL解決.在來就是研發過程中技術上解決方式的文件寫作,有可能當下因趕案件而沒寫,但事後這必須補齊,才能當作這整個case的結束.
這次雖然不是由設計到開發整個流程,但確是實戰的一個很大的體驗,很多東西也是面臨到才去解決的,而這次的裝備卻可能是下次一路順風的開始.
拿到這開發文件後有許多注意的要點在這之後要慢慢的記下來:
首先這是個很多畫面的應用程式,而真的需要這樣多的人力去開發嗎?第一次用C#,第一次拉那麼多的試窗介面,我們浪費很多的時間去試了很多東西,才得到了一些結果.
畫面分析:
畫面是很多沒錯,但是功能都差不多,而且如果一開始對這些都很默生的話,那必須集中人力去針對某些細節去討論,當完成了一個基礎的雛形後,就開始為程式的命名方式,寫做方法,做個規化,當討論到一個結果後就可以針對類似的畫面做苦功了,一個人做苦功常常會比分出兩三個人快,類似頁面,也比較能掌握命名方式.
分工合作:
由一個主要的人去領導,去掌握是一見重要的事,很多人只會做,就像球員一樣,但是缺少一個教練,後衛,跑壘指導員的話,多多少少是盲目的,而這樣的人不一定要是一個很會做的人,但是他是要能看出缺點.問題.和指導出方向,所以經驗是很重要的.
文件的寫作:
大部份的人都還沒有寫做文件的習慣,我也是!!雖然說能把事情解決,但是將文件製造出來卻是個問題,有可能寫出來的東西七零八落,這必須多學習一些相關的課程才能去好好的改善.首先機本上由開發文件所製造出的問題,由條例式的列出,並向PL解決.在來就是研發過程中技術上解決方式的文件寫作,有可能當下因趕案件而沒寫,但事後這必須補齊,才能當作這整個case的結束.
這次雖然不是由設計到開發整個流程,但確是實戰的一個很大的體驗,很多東西也是面臨到才去解決的,而這次的裝備卻可能是下次一路順風的開始.
星期六, 7月 09, 2005
VS .NEt & Eclipse
星期一, 7月 04, 2005
星期三, 6月 29, 2005
開發文件寫作
還沒有什麼頭序寫東西,但是這學期發現了一些問題
1.設計文件業怎樣寫
2.報計畫時的一些需求文件
3.如何去描述自己的專案
看了一本C#的書,我想先試看看他裡面的一些方法:
1.初步調查(可能是一通電話,一些想法,一些需求)
2.分析(資料收集)
3.設計(輸出設計,輸入設計)
4.開發
5.實作
6.稽查與維護
通常接到case大部份都是一些敘述和幾個特定功能的條例式:
一開始是序述基本的功能,在來條例式的把系項目給撰寫出來,比如說
1.程式將提供親切的使用者介面
2.能輸入使用者學生科系-xx之類的
以此類推
最後在加上一個簡單的範例加強設計後的樣式,最好還有圖表
最後將這些內容改成需求規格書,exsmaple:
一般說明:
程式介面:
包括
*三個選項,分出三個科系
*什麼按紐做些什麼事之類的
系統輸入: 運作規則:
大概分這些類
就可以依此先設計出外型,當然也就會有這些程式的文件,在來就市處理的設計,將所有的資料改成我們看的懂的邏輯圖,更方變撰寫程式,之後就進入開發階段,當然邊開發就可以找出些當時設計文件的問題,這些也要製成文件存參,什麼樣的問題用什麼樣的方式解決,之後即可以完成一個project,最後就是QA了.把自己的程式給別人去測試,最後就會有不一樣的結果.
1.設計文件業怎樣寫
2.報計畫時的一些需求文件
3.如何去描述自己的專案
看了一本C#的書,我想先試看看他裡面的一些方法:
1.初步調查(可能是一通電話,一些想法,一些需求)
2.分析(資料收集)
3.設計(輸出設計,輸入設計)
4.開發
5.實作
6.稽查與維護
通常接到case大部份都是一些敘述和幾個特定功能的條例式:
一開始是序述基本的功能,在來條例式的把系項目給撰寫出來,比如說
1.程式將提供親切的使用者介面
2.能輸入使用者學生科系-xx之類的
以此類推
最後在加上一個簡單的範例加強設計後的樣式,最好還有圖表
最後將這些內容改成需求規格書,exsmaple:
一般說明:
程式介面:
包括
*三個選項,分出三個科系
*什麼按紐做些什麼事之類的
系統輸入: 運作規則:
大概分這些類
就可以依此先設計出外型,當然也就會有這些程式的文件,在來就市處理的設計,將所有的資料改成我們看的懂的邏輯圖,更方變撰寫程式,之後就進入開發階段,當然邊開發就可以找出些當時設計文件的問題,這些也要製成文件存參,什麼樣的問題用什麼樣的方式解決,之後即可以完成一個project,最後就是QA了.把自己的程式給別人去測試,最後就會有不一樣的結果.
星期四, 4月 21, 2005
又開工了....這是新的開始
我開始認識MPEG的一天
剛開始對影像檔案並不了解
雖然說現在還是差不多
不過已經知道了一些東西
MPEG的影像是有一定格式的
比如說
00 00 01 xx
就帶表了某些影像或相關資訊的開始
這是以16進位的表示來看的
在來就是還沒壓縮的影像
yuv & rgb
rgb 是 r & g & b 一連串的 一個byte 接byte 上次玩的rgb影像是這樣沒錯!!
而
yuv 是 y u v 三種元素每一種元素串流之後接連串下一種元素
這樣講起來挺模糊的,而且現在也懶的打太多字
改天杯
不過這幾天要開始寫FGS的自調串流伺服器
真給他頭痛
socket也還沒弄好一些基本的.... 進度緩慢 ...><" 太嫩了
剛開始對影像檔案並不了解
雖然說現在還是差不多
不過已經知道了一些東西
MPEG的影像是有一定格式的
比如說
00 00 01 xx
就帶表了某些影像或相關資訊的開始
這是以16進位的表示來看的
在來就是還沒壓縮的影像
yuv & rgb
rgb 是 r & g & b 一連串的 一個byte 接byte 上次玩的rgb影像是這樣沒錯!!
而
yuv 是 y u v 三種元素每一種元素串流之後接連串下一種元素
這樣講起來挺模糊的,而且現在也懶的打太多字
改天杯
不過這幾天要開始寫FGS的自調串流伺服器
真給他頭痛
socket也還沒弄好一些基本的.... 進度緩慢 ...><" 太嫩了
訂閱:
文章 (Atom)